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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 62.01.11.000 - Этап №1: Техническое проектирование ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект ... 1 Общие сведения 1.1 Наименование системы Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. 1.2 Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры - Условная единица - 1,00 - 17 718 647,25 - 17 718 647,25

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект Значение характеристики не может изменяться участником закупки ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») 1 Общие сведения 1.1 Наименование системы Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. Значение характеристики не может изменяться участником закупки 1.2 Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры Значение характеристики не может изменяться участником закупки 1.3 Основания для выполнения работ 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; Значение характеристики не может изменяться участником закупки 10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010; 17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации Значение характеристики не может изменяться участником закупки 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» 11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»; 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 30.06.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего ТЗ (далее – Календарный план) Значение характеристики не может изменяться участником закупки 1.6 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5.1 настоящего ТЗ, в соответствии с Календарным планом и Контрактом Значение характеристики не может изменяться участником закупки 1.7 Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет. Тестовый стенд для проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний предоставляет Заказчик. Доступ к тестовому стенду Заказчик предоставляет Подрядчику на основании письменного обращения. Требования к предоставляемым вычислительным мощностям должны соответствовать требованиям, указанным в пояснительной записке, представляемой на этапе № 1 работ Значение характеристики не может изменяться участником закупки 2 Назначение и цели развития Системы 2.1 Назначение Системы Основными задачами, решаемыми в настоящий момент системой АСУ ТК, являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов контроля безопасности и устойчивости транспортного комплекса, управления в чрезвычайных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими органами государственной власти, а также гражданами и организациями Значение характеристики не может изменяться участником закупки АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными стратегическими целями развития АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и принятия мер по их устранению и ликвидации последствий 2.2 Цели развития Системы Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки Основными целями выполнения работ являются: – создание среды взаимодействия участников строительства на этапах реализации процесса строительства (реконструкции); – создание единого источника достоверной, непротиворечивой и верифицированной информации для принятия решений на всех управленческих уровнях; – повышение достоверности и прозрачности информации об инвестиционных проектах и программах; – повышение дисциплины формирования и предоставления плановых и отчетных форм; – обеспечение единого информационного пространства инструментам регистрации, хранения, согласования документов-обоснований; – обеспечение инструментов контроля полной стоимости, статей затрат по базовым, текущим ценам и ценам инвестиционного проекта, и физическим характеристикам; – обеспечение формирования графиков, контроля исполнения и сигнализация рисков неисполнения контрольных этапов; – повышение прозрачности процессов и оптимизация взаимодействия между различными участниками реализации инвестиционных проектов. Достижение указанных целей осуществляется для достижения стратегических целей развития АСУ ТК, указанных в пункте 2.1 ТЗ. Основные процессы, автоматизируемые в рамках выполнения Работ: – управление инвестиционными проектами строительства и реконструкции; – управление разработкой и согласование ПИР на всех стадиях реализации проекта; – управление задачами участников проектов строительства и реконструкции; – формирование и согласование исполнительной документации; – формирование и ведение календарно-сетевого планирования; – проведение процедуры строительного контроля; – формирование отчетности 2.3 Состав выполняемых задач Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей 3 Сведения об объектах автоматизации 3.1 Описание объектов автоматизации Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими органами государственной власти, гражданами и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. В соответствии с Аттестатом соответствия требованиям по защите информации АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Значение характеристики не может изменяться участником закупки 3.2 Текущее состояние объекта автоматизации АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи Значение характеристики не может изменяться участником закупки 1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП Текущая архитектура АСУ ТК приведена на рисунке 1. Рисунок 1 – Архитектурная схема АСУ ТК АСУ ТК осуществляет идентификацию и авторизацию посредством ЕСИА. Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3, СМЭВ 4, а также с использованием технологий API и FTP с учетом требований Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России», утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД. АСУ ТК развернута на вычислительных мощностях Головного центра обработки данных ФБГУ «СИЦ Минтранса России». На этапе технического проектирования Подрядчик формирует требования к необходимым вычислительным мощностям для разворачивания ПО, создаваемого в рамках настоящего ТЗ. В текущей конфигурации Подсистема «Мониторинга комплексного плана» (П-МКП) обеспечивает выполнение следующих основных функций: – обеспечение оперативного взаимодействия участников реализации КПМИ в цифровой форме при подготовке, изменении и реализации планов-графиков ФП КПМИ; – визуализация содержащихся в П-МКП данных, представление их в удобном для анализа виде; – ранжирование объектов планов-графиков ФП КПМИ, в соответствии с Методикой ранжирования отдельных мероприятий, включаемых в ФП КПМИ на период до 2024 года ; – мониторинг исполнения планов-графиков ФП КПМИ, включая сбор, обработку, представление данных, необходимых для мониторинга и формирования отчетов на основе данных мониторинга планов-графиков в соответствии с Методическими указаниями по мониторингу и внесению изменений в Комплексный план модернизации и расширения магистральной инфраструктуры на период до 2024 года (транспортная часть) и ФП КПМИ 3.2.1. Состав используемого ПО Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Значение характеристики не может изменяться участником закупки Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ) 3.3 Объект автоматизации в рамках настоящего Технического задания Предметом автоматизации является объединение в едином информационном пространстве данных по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, в отношении которых предусмотрена реализация мероприятий по строительству (реконструкции) в рамках национальных и федеральных проектов. Объекты автоматизации перечислены далее Значение характеристики не может изменяться участником закупки 3.3.1. Физические объекты Объекты транспортной инфраструктуры, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – автомобильные дороги федерального, регионального, межмуниципального и местного значения; – железнодорожные пути и станции, сопутствующая инфраструктура; – аэродромы и аэропортовые комплексы; – морские и речные порты, причалы, судоходные гидротехнические сооружения. Иные объекты, относящиеся к ведению Минтранса России, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – суда, в том числе аварийно-спасательный и вспомогательный флот; – пункты пропуска через государственную границу Российской Федерации Значение характеристики не может изменяться участником закупки 3.3.2. Информационные объекты Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) Значение характеристики не может изменяться участником закупки 3.3.3. Процессы автоматизации Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных Значение характеристики не может изменяться участником закупки 3.3.4. Взаимодействие участников Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах Значение характеристики не может изменяться участником закупки 4 Требования к Работам Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы Значение характеристики не может изменяться участником закупки 4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 Значение характеристики не может изменяться участником закупки 17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17 Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком. В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей Уровень хранения данных: – распределенные базы данных; – предзаполненный набор справочников, содержащих нормативно-справочную информацию; – отдельно вынесенный базовый функционал, обеспечивающий сохранение и обработку данных. Уровень информационного взаимодействия: – выполнение автоматизированных операций, обеспечивающих подготовку (агрегирование данных) и передачу данных между контурами. Уровень файлового хранения: – распределенная файловая система, обеспечивающая хранение и обработку загруженных в систему файлов. Уровень работы микро- и макросервисов: – запускаемые в асинхронном режиме application instance, нацеленные на выполнение отдельных ресурсоемких задач и использующие минимальный набор внутренних зависимостей, необходимых для выполнения задачи. При проектировании и разработке всех составляющих компонентов следует использовать единую методологию и единые принципы взаимодействия, надежности и управления 4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков № Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4 4.1.2 Требования к режимам функционирования П-МКП по результатам Работ П-МКП должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования должен быть штатный. В штатном режиме все подсистемы корректно и полностью должны выполнять свои функции. Перерывов в работе как П-МКП в целом, так и одного, либо нескольких компонентов, не предусмотрено. Режим регламентного (профилактического) обслуживания должен быть предназначен для проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе П-МКП с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию П-МКП и их периодичность должны быть определены Подрядчиком в процессе выполнения работ по созданию П-МКП. В режиме регламентного (профилактического) обслуживания П-МКП может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода П-МКП в данный режим, должен быть определен Подрядчиком Значение характеристики не может изменяться участником закупки Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.3 Показатели назначения В рамках выполнения работ по развитию Системы, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице 3. Таблица 3 – Определения показателей, связанных с количеством пользователей в подсистеме «Мониторинга комплексного плана» (П-МКП) № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечивать Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значение характеристики не может изменяться участником закупки Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице 4. Таблица 4 – Значения показателей количества пользователей подсистемы «Мониторинга комплексного плана» (П-МКП) № Показатель Значение 1 Расчетное количество пользователей 1000 2 Расчетное среднее количество одновременно работающих пользователей 500 Развитие Системы должно быть направлено на достижение следующих описаний ключевых результатов (ОКР), в рамках ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» мероприятия 1 ВПЦТ Минтранса России на период 2026-2028: · «Реализован функционал цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры подсистемы «Мониторинга комплексного плана» АСУ ТК». · «Проведено импортозамещение подсистемы «Мониторинга комплексного плана» АСУ ТК» 4.1.4 Требования к надежности функционирования и доступности для пользователей Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надежность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счет: – обеспечения требуемого уровня квалификации обслуживающего персонала; – регламентации и нормативного обеспечения выполнения работ обслуживающего персонала; – своевременной диагностики неисправностей. Расчетное значение коэффициента готовности АСУ ТК должно составлять не менее 0,95. Планы и процессы обеспечения непрерывности функционирования АСУ ТК должны быть увязаны с перечнем наиболее критических компонентов АСУ ТК, перечнем наиболее важных информационных ресурсов АСУ ТК Значение характеристики не может изменяться участником закупки ПО АСУ ТК должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов АСУ ТК; – сохранение работоспособности ПО при некорректных действиях пользователя; – резервное копирование БД Системы. Средства АСУ ТК по итогам развития должны обеспечивать следующие характеристики надежности при определенном уровне доступности функций: – операционное время: 24x7; – время восстановления работоспособности Системы после отказа или проведения регламентных работы: не более 4 часов; – отказоустойчивость на уровне 99% при единовременном обращении к Системе не менее 10 пользовательских сессий. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи публичных сетей. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Система должна автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом или исполняемых программных кодов Системы либо ее компонент) 4.1.5 Требования по диагностированию Системы Компоненты АСУ ТК должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО. АСУ ТК должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы. Диагностирование должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего ПО Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного ПО серверов Системы; – сбои и нарушения функционирования прикладного ПО серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в ПО диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы Значение характеристики не может изменяться участником закупки 4.1.6 Требования к транспортабельности Не предъявляются Значение характеристики не может изменяться участником закупки 4.1.7 Требования к эксплуатации и техническому обслуживанию Обслуживание Системы должно производиться обслуживающим персоналом. Допускается использование специализированных служб или подразделений на объектах внедрения для обслуживания и ремонта оборудования. При эксплуатации Системы должны использоваться штатные методы защиты от механических, тепловых, электромагнитных и других воздействий, защиты данных, в том числе, от несанкционированного доступа к ним, применяемые у Заказчика. Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Системы. При возникновении неисправностей должно осуществляться оперативное обслуживание Значение характеристики не может изменяться участником закупки 4.1.8 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется Значение характеристики не может изменяться участником закупки 4.1.9 Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего : – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; Значение характеристики не может изменяться участником закупки – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 17, 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 20, 20.14, 25(1) и 25(2) Требований, о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11.02.2013 № 17; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.10 Требования к безопасности исходного кода Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО Значение характеристики не может изменяться участником закупки Заказчик предоставляет результаты контрольных проверок, зафиксированных в артефактах сборочного процесса, Подрядчику для устранения в срок до даты завершения исполнения Контракта. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности и т.д., в случае, если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента 4.1.11 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Требования к эксплуатации оборудования Заказчик обеспечивает самостоятельно или с помощью привлеченных сторонних организаций. Для нормальной эксплуатации разрабатываемого ПО должно быть обеспечено бесперебойное питание серверов. При эксплуатации должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации серверов температура и влажность воздуха. Значение характеристики не может изменяться участником закупки 4.1.12 Требования по сохранности информации при авариях При аварийных ситуациях в АСУ ТК должна обеспечиваться сохранность информации. Реализуемые технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т. п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными Значение характеристики не может изменяться участником закупки 4.1.13 Требования к патентной чистоте и патентоспособности 4.1.13.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта Значение характеристики не может изменяться участником закупки 4.1.13.6. В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке) или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия – Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО; – должны передаваться исходный код, дистрибутивы, эксплуатационная и техническая документация. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности, предоставления правообладателям доступа к ПО и т.п.), не предусмотренные Контрактом 4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1.13.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке по соответствующему этапу исполнения контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности 4.1.13.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.13.4. Подрядчик должен подтвердить, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части и иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними 4.1.13.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам 4.1.14 Требования к численности персонала оператора Системы Дополнительные требования к численности персонала оператора не предъявляются Значение характеристики не может изменяться участником закупки 4.1.15 Требования к квалификации персонала Системы, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере, к системным администраторам предъявляются следующие требования: – знание основных принципов построения СУБД; – наличие расширенных знаний в области поддержки пользователей; – знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации Значение характеристики не может изменяться участником закупки 4.1.16 Требуемый режим работы персонала оператора Системы Режим работы персонала должен соответствовать действующему законодательству Российской Федерации (РФ) и обеспечивать работоспособность Системы согласно требованиям, предъявленным настоящим ТЗ. Должна быть учтена возможность сменного режима работы персонала Системы. При этом должна учитываться возможность круглосуточного подключения к работам специалистов, обеспечивающих функционирование Системы (администраторов и специалистов по техническому обслуживанию), для решения проблем по обеспечению работоспособности информационных ресурсов Системы Значение характеристики не может изменяться участником закупки 4.1.17 Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме, возможно, системных сообщений), должны быть на русском языке. Все экранные формы должны иметь текстовую справку, в которой должна быть описана инструкция по работе с данной экранной формой. На всех экранных формах при выполнении операций должна быть выведена индикация, которая информирует пользователя о статусе выполнения операции. Система должна обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введеенных значениях Значение характеристики не может изменяться участником закупки Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя манипулятора типа «мышь», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов. Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских веб-интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АСУ ТК должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АСУ ТК. Визуальное представление элементов пользовательского интерфейса АСУ ТК и состав отображаемой информации подлежат согласованию Заказчиком в процессе выполнения работ по модернизации Системы 4.2 Требования к содержанию работ 4.2.1 Архитектурное решение 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки 4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком 4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур. 4.2.2 Требования к масштабируемости и расчету мощностей 4.2.2.1 Модульность и горизонтальное масштабирование Архитектура ПО должна быть модульной и поддерживать горизонтальное масштабирование (scale-out) контуров без изменения исходного кода приложения. Функциональный контур масштабируется путем создания копий и подключения к сервису передачи агрегированных данных в информационно-аналитический контур. При этом могут применяться стратегии административного, функционального или географического разделения пользователей по экземплярам контура, в том числе с помощью настройки конфигурации приложения каждого экземпляра. Критичные компоненты, такие как серверы приложений, веб-сервисы и обработчики очередей, должны быть спроектированы как независимые, stateless (бессостоятельные, не сохраняющие состояние на самом сервере) сервисы. Хранение состояний приложения возможно с использованием СУБД. Это позволит увеличивать производительность и отказоустойчивость за счет добавления новых экземпляров сервисов в пул под нагрузкой балансировщика Значение характеристики не может изменяться участником закупки 4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ 4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов 4.2.3 Требования к функциональным блокам информационно-аналитического контура 4.2.3.1 АРМ Сотрудника Функциональный блок должен обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников: – сводной информации, полученной из функционального контура; – информации, сформированной в иных системах (программных продуктах) и загруженной с помощью импорта файла формата xlsx установленной структуры. Информация, собираемая и показываемая в АРМ Сотрудника, должна иметь возможность быть представленной как в рамках конкретного объекта, так и в рамках группы объектов, заданной набором фильтров. В состав данной информации должны входить показатели исполнения объекта, финансовые показатели, фиксация прохождения контрольных точек реализации исполнения. Для показа информационной сводной панели необходимо разработать функциональный блок настраиваемых аналитических панелей - компонент графического представления данных для отображения набора настраиваемых виджетов с возможностью создания (настройки) панелей для анализа информации по различным бизнес-процессам. Для формирования и выгрузки аналитических данных в форме табличного отчета необходимо разработать функциональный блок отчетности. Данный компонент должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов и достижении ключевых событий. Для сбора информации, необходимой для формирования аналитических панелей и отчетов, требуется разработать функциональный блок загрузки данных. Компонент должен обеспечивать регулярную автоматическую загрузку данных из контура функционального уровня в сводном агрегированном виде, достаточном для показа на панелях и для формирования отчетов. Кроме того, в компоненте должна быть предусмотрена возможность ручной загрузки данных в подготовленном формате Значение характеристики не может изменяться участником закупки 4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта) Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер должен представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также требуется реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания; – переход в информационный паспорт объекта во вкладке таблицы. Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов. Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Освоено» должен отображать освоение (принято) в млн. руб. с разделением по годам, с фильтрацией по признакам: – всего нарастающим итогом с начала реализации (до утв. паспорта ФП); – всего нарастающим итогом после утверждения паспорта ФП; – всего с начала отчетного года; – всего с начала отчетного месяца; – всего по контракту/контрактам. Виджет «Контрактация» должен отображать плановый объем финансирования по контракту/ контрактам в отношении к «Законтрактовано в млн. руб» с нарастающим итогом с начала отчетного года. Необходимо реализовать фильтрацию по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Контрактация по контрактам» должен отображать сводную информацию о видах и количестве контрактов, которые были заведены. Виджет «Обеспеченность машинами и механизмами» должен отображать наличие машин и механизмов по плановому и фактическому значению в разрезе объектов. Виджет «Динамика по трудовым ресурсам (чел.), машинам и механизмам (в ед.)» должен отображать привлечение трудовых ресурсов по плану-факту с возможностью фильтрации по периоду. Виджет «Строительная готовность объекта» должен отображать готовность объекта в процентах. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Паспорт объекта должен содержать следующие вкладки: – «Паспорт» (информация и параметры объекта, участники строительства, сведения о затратах с фильтрацией по бюджетам, проблемные вопросы); – «Показатели» с возможностью редактирования; – «Финансирование» (сведения о выделенных и доведенных д\с в разбивке по бюджетам); – «Контракты» (сведения о заключенных контрактах по объекту с возможностью редактирования); – «Строительный контроль» (количество выявленных недостатков по типам; – «Подробные сведения о выявленных недостатках» с возможностью редактирования; – «Проблемные вопросы» (сведения о проблемных вопросах в разбивке по типам); – «Задачи» (доступ к функциональному блоку по работе с задачами с возможностью создания новых задач); – «Фотогалерея» (изображения с площадки строительства объекта). Необходимо реализовать виджеты, отображающие аналитическую информацию о количестве контрольных точек (далее - КТ), отражающих ход реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, относящихся к ведению Минтранса России. Все виджеты данной группы должны иметь следующие фильтры по: – национальным и федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – статусу достижения; – видам работ (проектирование, получения заключения государственной экспертизы проектной документации, строительно-монтажные работы, ввод в эксплуатацию и др.) Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов должна раскрываться таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ. Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и их срок . Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о соблюдении ранее установленного срока, выполненных ранее срока, выполненных в срок, не выполненных в срок (срок истек), не выполненных (срок не наступил). Виджет «Контрольные точки, риски» должен отображать общее количество объектов, количество завершенных объектов, количество объектов с высокой степенью риска, со средней и умеренной/ отсутствующей. При нажатии на количество объектов должна открываться таблица с объектами и контрольными точками, отображающими текущую КТ, план и факт по каждой контрольной точке с подсвечиванием отставания соответствующим цветом. Зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев; Необходимо реализовать виджет, который отображает аналитическую информацию о текущих и прогнозных рисках и их влиянии на показатели национальных и федеральных проектов с возможностью выбора параметра (мощности), влияние на который оказывают объекты, и добавления фильтров по: – федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств 4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.3.4 Функциональный блок загрузки данных Функциональный блок предназначен для обеспечения информационного обмена со смежным контуром и должен обеспечивать получение (загрузку) актуальных данных по проектам, объектам, их финансированию и контрольным точкам исполнения. Данные должны сохранятся в функциональном блоке в агрегированном (сводном) виде и использоваться в качестве источника информация для построения виджетов аналитической панели, а также отчетов. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных; – преобразования данных; – сохранения данных; – хранения истории запусков. Должны быть реализованы следующие стратегии загрузки: – ручная загрузка данных, предоставленных в файлах; – автоматическая загрузка данных из смежного контура. Автоматический режим подразумевает под собой фоновую регулярную загрузку сводной информации, собранной на основе актуальных данных, вводимых в функциональные блоки Ручной режим загрузки должен обеспечивать возможность загрузки данных по шаблону. Файл для загрузки должен быть в формате *xlsx. Данные могут предоставляться как в полном объеме шаблона, так и в частичном. Функция преобразования данных из файла формата xlsx должна использовать следующие стратегии: – валидация данных на соответствие шаблону; – применение функций преобразования к отдельным полям источника данных, такие как приведение типов, преобразование формата даты; – агрегация данных по выбираемым категориям; – применение функций преобразования для получения вычисляемых значений; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция хранения истории запусков должна фиксировать следующую информацию: – дата и время загрузки; – название источника; – статус загрузки; – сообщение об ошибках (при наличии). При помощи шаблона предполагается загрузка следующей сводной информации по объектам строительства: – наименование объекта строительства, федерального проекта, инвестиционного проекта, указание местоположения и пр. основные характеристики; – общая информация об объекте, включающая в себя плановые и фактические показатели с детализацией по годам за 5 лет; – плановые и фактические показатели хода реализации, описывающие сроки достижения контрольных точек этапов проектирования и строительства; – плановые финансовые показатели с детализацией по годам и источникам финансирования, включающие в себя объем финансирования и план освоения; – плановые и фактические показатели по контрактации; – плановые и фактические показатели по обеспеченности машинами и механизмами; – плановые и фактические показатели по привлечению трудовых ресурсов; – информация о строительной готовности; – информация об уровне риска реализации и необходимым мерам. Данные, переданные в функциональный блок посредством ручной загрузки отчета, должны сохраняться как в сводном виде, подходящем для показа в аналитических панелях, так и фиксироваться в виде пакета (отчета) с сохранением времени загрузки и автора В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4 Функциональные требования к блокам функционального контура Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов Значение характеристики не может изменяться участником закупки 4.2.4.13 Функциональный блок ведения строительного контроля Необходимо разработать следующий функционал: – отражение результатов проведения инспекционной деятельности (проверки); – автоматическая генерация инспекционных документов (акт проверки и предписания) на основании зафиксированных недостатков; – работа с материалами фото и видеофиксация недостатков с возможностью сформировать отчеты о проведенных проверках и количестве выявленных недостатков; – формирование актов об устранении недостатков; – подписание актов проверки, актов инспекционного контроля, предписаний об устранении недостатков/о приостановке работ, отчета по устранению нарушений (с возможностью приложения документации, отправки отчета на почту), а также актов устранения недостатков; – формирование отчета по установленной форме; – разработка программы проведения инспекционного контроля по форме; – отображение статусов карточек документов и недостатков; – автоматическое направление участникам Проекта уведомлений о выявленных недостатках; – вызов инспектора строительного контроля на Объект (Уведомление о необходимости проведения СК на объекте оформляется на официальном бланке организации Генподрядчика. Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; – возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных из файлов формата xml; – преобразования данных; – сохранения данных; – фиксация выполненных действий по созданию/изменению в истории событий. Функция преобразования данных из файла формата xml должна использовать следующие стратегии: – валидация файла на соответствие xsd-схемам, утвержденным Минстроем России и опубликованным на официальном сайте как актуальные; – валидация данных файла на соответствие форматам ожидаемых данных и данным, уже имеющимся в П-МКП, в т.ч. проверка наличия и доступности пользователю объекта строительства, юридических лиц, указанных в документе. Полный набор критериев валидации должен быть разработан на этапе № 1 Календарного плана; – применение функций преобразования к отдельным полям источника данных, таким как приведение типов, преобразование формата даты; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования. Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция сохранения истории событий должна фиксировать в т.ч. следующую информацию: – дату и время события; – название события; – автора события; – сохраняемые или изменяемые данные Данные, полученные на основании загруженного файла, должны сохраняться в качестве документов или записей, соответствующих данному документу, с фиксацией всей информации, содержащейся в файле (в т.ч. объект строительства, юридические и физические лица, информация об объемах, суммах и пр). Файл формата xml, на основании которого создан документ или запись, должен быть прикреплен к карточке этой записи и доступен для скачивания. Документы и записи, созданные посредством загрузки данных из файлов xml, должны быть доступны загрузившему их пользователю в соответствующей вкладке АРМ Подрядчика, а также сотрудникам Заказчика, имеющим доступ к объекту строительства. Функциональный блок должен поддерживать возможность загрузки файлов с измененными данными по документу (новые версии документа) с возможностью связать созданный документ с его предыдущими версиями или обновить (заменить) данные в уже существующем документе без создания новой версии. Во втором случае файл, содержащий данные об изменениях, должен быть прикреплен в качестве новой версии исходного файла. В функциональном блоке должна быть возможность разграничения прав на загрузку отдельных видов документов, определяемая настройкой прав пользователей и ролевой моделью. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи – доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования); 4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана № п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии 6 Должна содержать таблицу с информацией из графика производства работ о планировании и расходовании средств и ресурсов в рамках процесса строительства. В плане должно отображаться распределение стоимостей по периодам в разрезе стоимостей или объемов работ. 7 Должна иметь возможность формирования суточного графика работ в диапазоне дат с возможностью подневного ввода фактически выполненного объема. 8 Должна быть возможность сравнения версий, имеющих связи между собой В рамках функционального блока требуется разработать следующий набор вкладок: – список доступных Подрядчику объектов с возможностью фильтрации по общей информации об объекте (тип, вид статус, адрес объекта, участники реализации и др.) и просмотра краткой информации по каждому из них. Общий перечень данных в карточке не должен превышать описанный в разделе функциональный блок «Информация»; – вкладки с реестрами загруженных документов с возможностью группировки по типам и объектам, с возможностью перехода к карточке документа; – карточки отдельных документов, содержащие в себе основную информацию о документе и его участниках, версию документа, прикрепленный файл в формате xml, на основании которого документ был создан, список замечаний, выданных по документу, возможность выполнения действий по согласованию и подписанию с использованием функционального блока для ведения электронного документооборота (СЭД); – вкладка загрузки данных из файлов формата XML по схемам, определенным Минстроем России для передачи документов в электронном виде и опубликованным на официальном сайте; – список пользователей, являющихся представителями Подрядчика и имеющих доступ к АРМ Подрядчика и конкретным объектам в нем, с возможностью управления доступом, подключением новых пользователей и блокировкой ранее подключенных. Необходимо предусмотреть возможность для администратора от Подрядчика управлять доступом отдельных пользователей к конкретным объектам строительства; – список аккаунтов для взаимодействия с внешней системой электронного документооборота, в случае использования Удостоверяющего центра для подписания документов с использованием КЭП (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); 4.2.4.4.3. Требования к созданию виджетов Необходимо разработать следующий функционал: – реализовать возможность точечной настройки аналитических виджетов по дате формирования данных (при необходимости); – выполнить возможность непосредственного перехода от информации на виджете дашборда к источникам данных; – реализовать возможность пользовательской настройки отображения и группировки виджетов Необходимо разработать следующий функционал: – возможность формирования графика производства работ по проекту, в том числе на основании загруженных смет; – возможность формирования сущностей типа «запись ГПР», «Суммарная запись ГПР», «веха»; – возможность ручного добавления, удаления и перемещения по структуре работ в графике; – формирование зависимостей между работами в ГПР с установкой временных задержек; – возможность редактирования внесенного этапа работ; – назначение ответственных и исполнителей на конкретные работы графика, возможность делегирования работ; – возможность полного или частичного делегирования графика в другие версии; – возможность полуавтоматического переноса фактических показателей из делегированной версии в основную; – поддержка версионности и стадийности графиков; – возможность формирования директивной версии графика (базового плана) и заполнения новой версии ГПР на ее основании; – возможность копирования версии ГПР; – возможность сравнения связанных версий графиков между собой; – автоматический расчет критического пути с возможностью отображения только тех работ, которые принадлежат критическому пути; – автоматический расчет прогнозных сроков выполнения работ на основании динамики фактического выполнения работ; – настройка визуального отображения диаграммы Ганта; – возможность удалить этап работ из графика; 4.2.4.4.3.5. Виджеты по тематике «Отображение аналитической информации по объектам и направлению на панели руководителя проекта» Группа виджетов должна отображать текущие показатели по объекту направления. У группы виджетов должен быть предусмотрен фильтр по направлениям (воздушный транспорт, железнодорожный транспорт, морской транспорт, речной транспорт): – стоимость контракта; – дефицит (отображает разницу между доведенными лимитами и стоимостью объекта по ССР); – непогашенный аванс (разница между суммой выданного аванса и погашенного по КС-3); – банковская гарантия с указанием даты завершения (из контрактов); – строительная готовность объекта, отображаемая в процентах, и динамика за неделю по задействованным трудовым ресурсам (чел.) и машинах и механизмах (в ед.); – характеристика объекта; – эффекты, которые оказывает объект строительства; – необходимые решения; – ход исполнения; – фотография объекта. Также по объекту из направления должна отображаться таблица с диаграммой Ганта со столбцами: – номер по порядку; – наименование объекта; – длительность (дней); – начало (дата); – окончание (дата); – диаграмма с разделением по кварталам. Виджет «Отчет по объекту» должен содержать три окна: – в первом окне – «Эффект от реализации»; – во втором окне – «Информация об объекте/Проблемные моменты» со следующим перечислением: 1) поле «Заключен ГК» (необходимо указать юридическое лицо, с которым заключен контракт), далее необходимо показать вид работ из контракта, дату заключения договора и номер контракта; 2) отображение информации о текущей контрольной точке объекта и плановой дате; 3) информация по контракту (дорожная карта); 4) дата ввода объекта в эксплуатацию с комментарием); 5) поле «Виды работ»; 6) изменения количества рабочих/техники с разбивкой по месяцам с даты начала СМР; – в третьем окне – «Предложения по решению проблем» 4.2.4.2 АРМ Заказчика Функциональный блок АРМ Заказчика должен включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны Заказчика доступом к АРМ Подрядчика для сотрудников Подрядчиков. Функционал должен обеспечивать следующие возможности: – просмотр списка новых объектов строительства; – возможность перехода к карточке объекта, возможность добавления новых объектов; – просмотр списка юридических лиц, выступающих Подрядчиками на проектах, возможность просмотра информации о них, добавления новых, редактирования и удаления созданных ранее; – возможность создания АРМ Подрядчика для юридических лиц, выполняющих работы на объекте; – просмотр списка пользователей, являющихся представителями подрядчика, управление их доступом к АРМ Подрядчика, возможность добавления новых и блокировки неактуальных (уволенных, прекративших свою деятельность по проекту). Функциональный блок должен разрабатываться в интерфейсах, аналогичных АРМ Подрядчика. Информация представляется в виде вкладок, осуществляющих: – работу с объектами строительства; – работу и управление Подрядчиками; – настройку АРМ Подрядчика; – управление пользователями АРМ Подрядчика; – просмотр и работу с предоставленными документами через механизм загрузки в формате XML. Объем данных, выводимых в каждой вкладке, регулируется правами доступа пользователя-администратора Заказчика к объектам и юридическим лицам. Доступ к АРМ Заказчика в целом и к конкретным вкладкам в нем, должен управляться настройкой прав пользователя. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией 4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.4.2. Требования к отображению объекта на интерактивной схеме Функционал должен включать отображение объектов на интерактивной схеме РФ, расположенной на аналитической панели – дашборд. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта). Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также необходимо реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры); – годам; – Заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана – Виджет «Текущая аналитика СМР по ГПР» должен отображать данные по выполненным работам и освоенным средствам. Учитываются только данные из актуальных ГПР стадии СМР; – Виджет «Мониторинг исполнения ГПР, СМР» должен отображать сводную информацию о сроках исполнения плановых графиков ГПР по работам СМР (в сравнении с фактическими датами начала/окончания работ в ГПР); – Виджет «Мониторинг строительного контроля» должен отображать информацию о недостатках, выявленных в ходе проверок инспектором строительного контроля по всем объектам базы; – Виджет «Недостатки» должен отображать информацию о количестве недостатков, выявленных в ходе проверок строительного контроля в разбивке по их текущему статусу; – Виджет «Качество исполнительной документации» должен отображать количество документов, находящихся на согласовании, количество подписанных ЭП и количество выданных замечаний к документации; – Виджет «Стадии реализации (текущие)» должен отображать количество объектов по текущим стадиям реализации строительства, указанным в функциональном блоке «График производства работ» 4.2.4.4.3.3. Виджеты по тематике «Управление проектами» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Статус объектов проектирования и строительства» должен отображать статус объектов; – Виджет «Актуальные вопросы (количество, статусы)» должен отображать количество и статусы по актуальным вопросам по объектам; – Виджет «Технико-экономические показатели реализуемых объектов» должен отображать сводную информацию об основных технико-экономических показателях объектов; – Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов раскрывается таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ; – Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и срок которых не наступил. Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о выполненных ранее срока, выполненных в срок и «Не выполнено. срок истек», «Не выполнено. Срок не наступил» 4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам 4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации) Также на данном дашборде необходимо отобразить: – столбчатую горизонтальную диаграмму «Бюджетные обязательства/ Касса по годам», в которой должны отображаться данные показатели в разрезе по годам. Ниже должна быть отображена таблица с данной информацией; – столбчатую горизонтальную диаграмму «Авансы», отображающую информацию на текущий год: 1) всего аванса по контракту; 2) раскассировано аванса (сумма, которую Подрядчик может потратить со счета авансовых средств. Данные поступают от Подрядчика в виде сведений об операциях для утверждения. Источник данных – система «Электронный бюджет» (можно выгрузить в виде отчета в формате *xls); 3) выплачено аванса (фактическая сумма, перечисленная Подрядчику по выставленным им счетам. Данные поступают из бухгалтерии и также могут быть получены из «Электронного бюджета»); 4) остаток к выплате (показатель рассчитывается как разница между стоимостью контракта, выплаченного аванса и оплаты по КС-2 (актам выполненных работ); 5) зачтено аванса (часть суммы аванса, которая закрывается (засчитывается) при выполнении работ и подписании актов по КС-2 (акты выполненных работ). Таким образом, сумма к оплате по новым актам уменьшается на размер зачтенного аванса); 6) неотработанный аванс (сумма перечисленного аванса, которая еще не закрыта (не зачтена) актами выполненных работ (КС-2), то есть это разница между выплаченным авансом и суммой, которая уже была зачтена); – кольцевую диаграмму «Работы», с информацией по: 1) выполненным работам; 2) остатку к выполнению 4.2.4.4.3.7. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по нескольким объектам из направления» Данный дашборд должен отображать таблицу «светофор» со списком всех объектов по направлениям и со следующими столбцами: – номер по порядку; – наименование объекта; – подрядчик (если договор расторгнут, то необходимо отобразить статус и дату, также если договор планируется расторгнуть или он в процессе расторжения); – стоимость объекта (млрд); – дата начала; – дата завершения; – готовность. Объекты должны быть распределены в таблице и окрашены в соответствующие цвета в зависимости от риска реализации объекта. При наличии риска реализации объекта строка с наименованием объекта должна окраситься в красный, при наличии умеренного риска - в желтый, при отсутствии риска - в зеленый). Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана – возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки) 4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/) 4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9.2. Требования формированию плана освоения. Раздел функционального блока «ГПР» - вкладка «План освоения» Необходимо иметь возможность учитывать все виды ресурсов: материалы, машины и механизмы, рабочую силу, а также планировать их потребление. Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» представлены в таблице 7. Таблица 7 – Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» № п/п Функциональность вкладок 1 Должен формироваться план освоения в объемах и деньгах на основании графика работ с возможностью детализации по настраиваемым периодам распределения, настраиваемым типом расчета. В рамках плана освоения должна отображаться информация по плановым, фактическим показателям, показателям по директивному плану и закрывающим документам, а также показатели по отклонениям (план-факт, план-закрыто, факт-закрыто). 2 Должен отображаться ресурс типа -материалы. 3 Должен отображаться ресурс типа -машины и механизмы. 4 Должен отображаться ресурс типа -рабочая сила и кадры. 5 Должен позволять формировать накопительную ведомость Также необходимо настроить систему уведомлений на почту ___@___ в системе. В уведомлении указываются сведения: 1) об объекте капитального строительства с указанием адреса (местоположения) объекта и времени проведения контрольных мероприятий; 2) о предъявляемых к освидетельствованию видов (этапов) работ, конструкций с указанием осей, пикетов, рядов, отметок или иных привязок мест расположения объекта освидетельствования и об участниках строительства, привлекаемых для выполнения указанных работ; – формирование аналитической информации по недостаткам; – отображение типовых нарушений со ссылкой на нормативные правовые акты; – замещение инспектора строительного контроля; – добавление недостатков, которые устранены в ходе проверки; – привязка недостатков к элементам BIM моделей; – привязка проверок к ПД/РД/ИД; – привязка недостатков к элементам графика производства работ; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом 4.2.4.14 Функциональный блок ведения договоров «Управление проектом» Необходимо разработать следующий функционал: – формирование категорий контрактов; – формирование контрактов с указанием статусов, основных показателей и условий, предусмотренных контрактом (обязательства, авансы, дополнительные соглашения, гарантийные удержания и др.); – формирование и учет платежей по контрактам с привязкой к типу, план/факт, не законтрактовано (год) и типу бюджета; – формирование дополнительных соглашений к контракту с автоматическим изменением суммы, плановой даты начало/окончания контракта; – аналитика контрактов по текущим статусам, видам и типам выполняемых работ на объекте. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.8 Функциональный блок «Информация» Данный функциональный блок содержит требования к функциям ведения карточек проектов и программ. В рамках выполнения Работ необходимо организовать ввод, обмен и хранение, и актуализацию данных по проектам и программам. Карточка объекта/программы должна содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и Подрядчиков по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков). Виды информации: – общая информация об объекте строительства (тип, вид статус, адрес объекта, участники реализации и др.); – данные по освоению денежных средств (кассовое исполнение, оплачено по контрактам, риск неосвоения лимитов); – отображение всех показателей объекта (технико-экономические показатели, статус реализации, градостроительная проработка и др.); – информация по финансированию объекта (выделение и доведение денежных средств); – информация по контрактам объекта; – информация по вопросам, возникающим в ходе реализации; – данные по выполнению задач по объекту; – фотогалерея; – видеонаблюдение в режиме реального времени. При открытии карточки объекта должен открываться функциональный блок «Информация», в котором указывается сводная информация по объекту, разделенная по вкладкам согласно таблице 5 4.2.4.16 Функциональный блок для ведения электронного документооборота Необходимо разработать инструмент для согласования документов, связанных с реализацией проектов. Требования к разрабатываемому функционалу функционального блока «СЭД»: – работа в СЭД с такими типами документов как: письма, контракты, закупочная документация, проектная/рабочая/исполнительная документация, соглашения, отчеты, первичные документы, приказы, протоколы, распоряжения, положения, служебные/докладные/пояснительные записки, аналитические справки, доверенности. Справочник типов документов должен быть открытый и при необходимости дополняемый; – обеспечение действий Пользователя в СЭД с документами внутреннего и внешнего, документооборота: делегирование, согласование, перенаправление, многостороннее согласование, многостороннее подписание. Реализовать возможность процедуры формирования маршрутов для согласования/подписания документов; – отображение в экранной форме Пользователя в СЭД таких параметров для каждого обрабатываемого документа, как: отправитель и получатель документа, заголовок документа, дата документа, автор документа, тип и статус обрабатываемого документа, крайний срок выполнения связанной с документом задачи. Реализовать возможность фильтрации по указанным параметрам для перечня обрабатываемых Пользователем документов; – формирование документов. Реализовать возможность устанавливать взаимосвязи создаваемых документов с уже существующими в СЭД; возможность формировать приложения к письмам для различных типов файлов, размещенных в т.ч. на ПК Пользователя; поиск по наименованию/ заголовку документа в СЭД по произвольному вводу символов для существующих в СЭД документов; содержать «Тэги» для быстрого поиска созданного письма в системе; возможность указывать метки «прочитано», «не прочитано» для входящей документации; возможность настройки Пользователем на экранной форме СЭД требуемых для отображения параметров; – наличие истории документооборота, сохраняющего записи о всех событиях и их авторах в отношении каждого документа; – интеграция СЭД с вкладкой Планировщик задач, разделом «внутрисистемная почта» и разделом «уведомления». Организация списка документов: – создание раздела «Документы» в АРМ Подрядчика в соответствии с персональными возможностями доступа пользователя к документам; – ведение списка документов с разбивкой по процессам (этапам) и статусам документа: – карточка документа – этап для формирования карточки документа; – согласование – этап для согласования карточки документа с выделением следующих статусов: 1) на согласовании (получено согласование не от всех подписантов); 2) отменено инициатором (маршрут согласования снят инициатором); 3) согласовано (всеми подписантами); 4) отказано (получен отказ хотя бы от одного подписанта); – хранение документов с завершенным или отклоненным согласованием, организованно списком записей справочника, с предоставлением в табличном или ином виде. Должна быть реализована возможность поиска по атрибутам среди документов, доступных к просмотру: – наименование документа; – тип документа; – инициатор; – по связям с сущностями. Должна быть реализована возможность фильтрации документов по атрибутам, по этапам и статусам, по признаку «Я исполнитель», «Я инициатор», «Требует действий» Необходимо разработать следующий функционал: – автоматическое формирование плана освоения на основании сформированного графика с отображением данных, введенных в ГПР в табличной форме по различным разрезам (стоимости и объемы работ) с возможностью выбора детализации отображения по временным периодам (день / неделя / месяц / квартал / год) и типу отображения (раздельно или накопительно) и возможностью отображения различных показателей – работы / материалы / машины и механизмы / рабочая сила и кадры; – автоматическое создание плана освоения денежных средств и физических объемов выполняемых работ в разрезах рабочей силы (чел-час), ресурсов машин и механизмов (маш-час), материалов (ед. изм.); – возможность настройки отображения показателей, а также настройки диапазона дат; – формирование графика фактического освоения денежных средств и объемов по кварталам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.10 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Необходимо разработать следующий функционал: – реализация многоуровневого списка категорий документов ПИР с предустановленными значениями категорий и возможностью добавлять категории самим пользователем в случае необходимости; – наличие предустановленных шаблонов печатных форм документов «Задание на проектирование» и «Задание на инженерные изыскания», возможность выгрузить из документа в виде текстового документа; – реализация процедур согласования и подписания с помощью ЭП документов «Задание на проектирование» и «Задание на инженерные изыскания», «Программа инженерных изысканий» с отображением статуса согласования и подписания соответствующего документа; – возможность сформировать шаблон согласования и указание информации требуется ли наличие предыдущего согласования для этого уровня для выполнения процедуры согласования; – ввод, сортировка и хранение ИРД, проектной и рабочей документации в виде вложенных файлов документации ПИР; – согласование проектной документации с отображением статуса; – формирование и ведение реестров ИРД, проектной и рабочей документации; – возможность формирования документов с сохранением версий для отслеживания изменений проектной и рабочей документации; – реализация механизма работы пользователей с замечаниями к каждому отдельному документу ПИР, ДПТ; – процедура устранения замечаний исполнителем путем возможности внесения в карточку документа в разделе работы с замечаниями ответа о результатах работы над замечанием, включая прикрепления откорректированного документа (если требуется); – формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы; – процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий; – просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»: 4.2.5 Общие требования к функционированию 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ Значение характеристики не может изменяться участником закупки 4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02 4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы 4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.5.3 Требования к обмену сообщениями В рамках выполнения Работ реализуется встроенный мессенджер, позволяющий обмениваться сообщениями между пользователями АРМ. Требования к разрабатываемому функционалу: – создание персональных чатов из списка пользователей из раздела мессенджера; – создание групповых чатов из раздела мессенджера; – возможность отправки текстовых сообщений и файлов; – поиск по списку чатов; – возможность удаления созданного чата; – корректировка перечня участников группового чата; – индикация групповых чатов в списке 4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления Значение характеристики не может изменяться участником закупки 4.3.5 Требования по применению систем управления хранилищами и базами данных Для хранения данных должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – наличие сертификата соответствия ФСТЭК России требованиям по защите информации, предъявляемым к системам управления базами данных не ниже 5 класса защиты; – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологической в инфраструктуре Заказчика. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика. 2) Допускается использование только кластеризованных баз данных. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре Заказчика. 3) Решение должно быть отказоустойчивым. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов. 4) Любые соединения, устанавливаемые решением, должны быть защищенными*. Примечания: 1 Защищенные соединения, выходящие за пределы контролируемой зоны, должны быть защищены с помощью программных и/или программно-аппаратных шифровальных (криптографических) средств, сертифицированных ФСБ России (далее – СКЗИ). 2 Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД; 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. Использование учетных записей с административными полномочиями не допускается 4.3.2 Требования к организации хранилища данных Для хранения информации должна использоваться СУБД с возможностями распределенного хранения данных по кластерным узлам. СУБД предоставляется Заказчиком после завершения этапа № 1 Календарного плана. Структура БД должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в БД Системы. При проектировании структуры БД для хранения данных необходимо провести анализ реализованной структуры БД для П-МКП в целях использования в создаваемых АРМ. В результате анализа Подрядчик обязан представить Заказчику в Пояснительной записке описание структуры БД для функционирования АРМ с указанием переиспользуемых и вновь создаваемых таблиц БД. Информация должна размещаться в БД по возможности в нормализованной форме. Допускается использование дополнительных ненормализованных структур данных для повышения производительности. Допускается размещение отдельных параметров конфигурации во внешних конфигурационных файлах. Допускается размещение данных в нереляционных СУБД в случаях, предусматривающих очевидную выгоду в производительности, оптимизации требуемого места для хранения данных или необходимых вычислительных ресурсах по согласованию с Заказчиком. Полный перечень используемых программных решений должен быть определен Подрядчиком и согласован Заказчиком на этапе № 1 Календарного плана 4.3.4 Требования к информационному обмену между компонентами Системы Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет 5 Состав и содержание работ по развитию АСУ ТК В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) Значение характеристики не может изменяться участником закупки 5.1 Состав работ и график их выполнения (календарный план) 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 Значение характеристики не может изменяться участником закупки Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Сроки, установленные Календарным планом для каждого подпункта в рамках этапов, согласно таблице 11, включают подготовку, согласование, утверждение (для тех документов, в отношении которых требуется согласование или утверждение) отчетных, технических, рабочих документов с Заказчиком. Досрочная сдача результатов допускается по согласованию с Заказчиком. Сокращение периода (длительности) проведения опытной эксплуатации недопустимо. График выполнения работ по развитию АСУ ТК приведен в таблице 11. Таблица 11 – График выполнения работ по развитию АСУ ТК № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа Ожидаемые результаты работ 1 Техническое проектирование. 1.1. Разработка частного технического задания Начало: с даты заключения контракта Окончание: не позднее 19.01.2026 Сопроводительным письмом предоставлены Заказчику: Частное техническое задание. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 1.2. Разработка технического проекта Начало: 19.01.2026 Окончание: не позднее 26.01.2026 Сопроводительным письмом предоставлены Заказчику: Технический проект в составе: - Описание архитектуры системы; - Пояснительная записка, включая описание автоматизируемых функций; - Описание программного обеспечения; - Описание информационного обеспечения; - Ведомость технического проекта; - Ведомость машинных носителей информации; - Руководство по безопасной разработке программного обеспечения. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу) 2 Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Сопроводительным письмом предоставлены Заказчику: Исходные коды разработанного (передаваемого) программного обеспечения; Дистрибутивы разработанного (передаваемого) программного обеспечение; Инструкция по сборке; Паспорт П-МКП; Описание П-МКП; Руководство администратора; Руководства пользователей на каждый АРМ, включая рекомендуемые характеристики к ПК для АРМ; Документы по испытаниям в составе: - Программа и методика предварительных испытаний; - Протокол предварительных испытаний; - Программа и методика опытной эксплуатации; - Акт ввода в опытную эксплуатацию; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026 6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ Значение характеристики не может изменяться участником закупки 6.2 Виды, состав, объем и методы испытаний и его составных частей В случае выявления ошибок в ПО П-МКП при проведении предварительных испытаний, Подрядчик должен их устранить до начала момента проведения опытной эксплуатации. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки). Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены Подрядчиком в документе «Программа и методика опытной эксплуатации». Программа и методика опытной эксплуатации должна быть утверждена Заказчиком до проведения опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» (с приложением журнала опытной эксплуатации) и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации, подтверждающий готовность П-МКП АСУ ТК и ее допуск к приемочным испытаниям Значение характеристики не может изменяться участником закупки Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный Результаты проведения предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от ТЗ оформляются как недостатки работ. Прочие недостатки могут документироваться как рекомендации. Наличие рекомендаций не влияет на процесс передачи П-МКП АСУ ТК в эксплуатацию. В случае значительного отклонения П-МКП АСУ ТК от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены или расширены Заказчиком. По результатам выполнения этапа № 3 должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии и сроки проведения испытаний. Испытания проводятся на площадке, указанной в программе и методике соответствующих испытаний, опытной эксплуатации. В состав комиссии включаются ответственные лица Заказчика и Подрядчика, а также, при необходимости, специалисты иных внешних организаций (например, экспертных), привлекаемые Заказчиком. Подрядчик обязан уведомить Заказчика о готовности к проведению испытаний официальным сопроводительным письмом и предоставить Заказчику программу и методику испытаний (далее – ПМИ). Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком и Подрядчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытаний и Акт о приемке в опытную эксплуатацию, подтверждающий готовность П-МКП АСУ ТК к следующему виду испытаний – опытной эксплуатации Состав мероприятий, включенных в пилотную зону, может быть изменен по согласованию с заказчиком. В случае выявления ошибок в ПО П-МКП при проведении опытной эксплуатации, Подрядчик должен их устранить до начала приемочных испытаний. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки) Методы приемочных испытаний и порядок их проведения должны быть определены в документе «Программа и методика приемочных испытаний», который должен быть подготовлен Подрядчиком и утвержден Заказчиком до начала приемочных испытаний. По результатам проведения приемочных испытаний оформляются Протокол приемочных испытаний и Акт готовности П-МКП к эксплуатации. В Протоколе приемочных испытаний должны быть указаны перечень проверяемых сервисов, функций, возможностей, дата и время проведения приемочных испытаний, состав приемочной комиссии, рекомендации (при наличии) к решению, а также выводы о готовности П-МКП АСУ ТК к вводу в эксплуатацию. Ввод П-МКП АСУ ТК в эксплуатацию осуществляется после выполнения работ по ИБ, подписанием соответствующего акта 6.3 Порядок контроля и приемки выполненных работ Сдача-приемка выполненных работ осуществляется в соответствии с условиями Контракта. Сдача-приемка работ осуществляется по завершении каждого этапа в порядке, установленном в Контракте Значение характеристики не может изменяться участником закупки 6.3.1 Условия о порядке предоставления (передачи) результатов выполнения работ Заказчику Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ, а также в соответствии с инструкциями, приведенными в рабочей документации на П-МКП. Документация на П-МКП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика Значение характеристики не может изменяться участником закупки Передача исходных кодов, разработанных и/или передаваемых в ходе выполнения работ программ для электронных вычислительных машин (далее - программа для ЭВМ) и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных и/или передаваемых в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает заказчику исходные коды, дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения. 6.4 Сведения о гарантийном обслуживании Гарантийный срок: один год с даты подписания Заказчиком документа о приемке Этапа № 3. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, включая замечания и комментарии от федеральных органов исполнительной власти в области обеспечения безопасности, федерального органа исполнительной власти, уполномоченного в области противодействия техническим разведкам и технической защиты информации, Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерства транспорта Российской Федерации и Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций, выявленных после приемки выполненных Работ, в том числе в документации, разработанной по результатам выполненных Работ, касающиеся соответствия требованиям нормативных правовых актов, действующих на момент завершения этапа № 2. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, установленные Заказчиком в Акте с перечнем выявленных недостатков. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Гарантийным случаем признается полное или частичное отсутствие функционирования П-МКП и ее компонентов в результате выполнения работ по настоящему Техническому заданию. Подрядчик должен обеспечить гарантию работоспособности П-МКП, включая гарантийную поддержку Значение характеристики не может изменяться участником закупки В рамках гарантийной поддержки П-МКП Подрядчик должен: – устранять обнаруженные в процессе постоянной эксплуатации дефекты в работе П-МКП в срок не более 5-ти рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); – принимать участие в восстановлении работоспособности П-МКП после сбоев и аварий, вызванных дефектами и недокументированными возможностями подсистемы, выполняя при этом работы, связанные с восстановлением целостности данных и обновлением П-МКП; – вносить изменения в техническую и рабочую документацию на функциональные блоки, на основании выявленных неточностей или обнаруженных недокументированных возможностей подсистемы; – консультировать представителей Заказчика об особенностях реализации П-МКП, в том числе при установке, настройке и пуско-наладке Системы; – давать ответ на заявку Заказчика в течение 1 (Одного) рабочего дня с момента ее поступления 7 Источники разработки Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» Значение характеристики не может изменяться участником закупки Приложение А к Техническому заданию Таблица А.1 – Описание состава загружаемых данных по мероприятиям Раздел данных Подраздел данных Название атрибута Общая информация об объекте - Наименование Федерального проекта - Инвестпроект - Участок - Длина участка, км Провозная способность, млн. тонн в год план факт Пропускная способность, пар поездов в сутки план факт Максимальная весовая норма поездов, тонн план факт - Наименование мероприятия/объекта - Код объекта - Ответственный исполнитель/ заказчик (контакты) - Субъект Российской Федерации/фактическое (местоположение объекта) - Код ИП - Назначение объекта, основные характеристики объекта (ТЭП) - Предварительная стоимость по ФП (млн. руб.) Ход реализации (Проектирование) Заключен контракт на инженерные изыскания ПД план факт Направление ПД на ГГЭ план по условиям договора факт Получение заключения государственной экспертизы на ПСД план по условиям договора факт стоимость по итогам заключения ФАУ «Главгосэкспертиза России» - Сроки по ПОС Ход реализации (Строительство) Проведение конкурсных процедур на выполнение СМР Объявление торгов (план) Объявление торгов (факт) Заключение контракта на СМР (план) Заключение контракта на СМР (факт) Оформление земельно-правовых отношений* план факт выполнение в % Получено РС план факт Ввод объекта во временную эксплуатацию план факт Получен ЗОС план факт Ввод объекта в эксплуатацию (РВ) план по условиям договора* факт отклонение (дни) - Примечание Обеспеченность машинами и механизмами - план факт - - Строительная готовность (в %) Привлечение трудовых ресурсов, чел. - план факт - - Уровень риска реализации (определяется по наличию отставаний по контрольным точкам, влияющих на срок ввода в эксплуатацию) Объем финансирования в соответствии с ФП (млн. руб.) Год, по которому сформирован отчет Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Сводная бюджетная роспись на отчетную дату Значение характеристики не может изменяться участником закупки Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект - - Значение характеристики не может изменяться участником закупки - ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») - 1 Общие сведения 1.1 Наименование системы - Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование Заказчика и Подрядчика - Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры - - Значение характеристики не может изменяться участником закупки - 1.3 Основания для выполнения работ - 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; - - Значение характеристики не может изменяться участником закупки - 10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010; - 17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ - 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации - - Значение характеристики не может изменяться участником закупки - 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - 11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»; - 1.5 Сроки начала и окончания работ - Начало работ: с даты заключения Контракта. Окончание работ: не позднее 30.06.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего ТЗ (далее – Календарный план) - - Значение характеристики не может изменяться участником закупки - 1.6 Порядок оформления и предъявления результатов работ - Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5.1 настоящего ТЗ, в соответствии с Календарным планом и Контрактом - - Значение характеристики не может изменяться участником закупки - 1.7 Место выполнения Работ - Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет. Тестовый стенд для проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний предоставляет Заказчик. Доступ к тестовому стенду Заказчик предоставляет Подрядчику на основании письменного обращения. Требования к предоставляемым вычислительным мощностям должны соответствовать требованиям, указанным в пояснительной записке, представляемой на этапе № 1 работ - - Значение характеристики не может изменяться участником закупки - 2 Назначение и цели развития Системы 2.1 Назначение Системы - Основными задачами, решаемыми в настоящий момент системой АСУ ТК, являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов контроля безопасности и устойчивости транспортного комплекса, управления в чрезвычайных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими органами государственной власти, а также гражданами и организациями - - Значение характеристики не может изменяться участником закупки - АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными стратегическими целями развития АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и принятия мер по их устранению и ликвидации последствий - 2.2 Цели развития Системы - Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - Основными целями выполнения работ являются: – создание среды взаимодействия участников строительства на этапах реализации процесса строительства (реконструкции); – создание единого источника достоверной, непротиворечивой и верифицированной информации для принятия решений на всех управленческих уровнях; – повышение достоверности и прозрачности информации об инвестиционных проектах и программах; – повышение дисциплины формирования и предоставления плановых и отчетных форм; – обеспечение единого информационного пространства инструментам регистрации, хранения, согласования документов-обоснований; – обеспечение инструментов контроля полной стоимости, статей затрат по базовым, текущим ценам и ценам инвестиционного проекта, и физическим характеристикам; – обеспечение формирования графиков, контроля исполнения и сигнализация рисков неисполнения контрольных этапов; – повышение прозрачности процессов и оптимизация взаимодействия между различными участниками реализации инвестиционных проектов. Достижение указанных целей осуществляется для достижения стратегических целей развития АСУ ТК, указанных в пункте 2.1 ТЗ. Основные процессы, автоматизируемые в рамках выполнения Работ: – управление инвестиционными проектами строительства и реконструкции; – управление разработкой и согласование ПИР на всех стадиях реализации проекта; – управление задачами участников проектов строительства и реконструкции; – формирование и согласование исполнительной документации; – формирование и ведение календарно-сетевого планирования; – проведение процедуры строительного контроля; – формирование отчетности - 2.3 Состав выполняемых задач - Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей - 3 Сведения об объектах автоматизации 3.1 Описание объектов автоматизации - Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими органами государственной власти, гражданами и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. В соответствии с Аттестатом соответствия требованиям по защите информации АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - - Значение характеристики не может изменяться участником закупки - 3.2 Текущее состояние объекта автоматизации - АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи - - Значение характеристики не может изменяться участником закупки - 1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП - Текущая архитектура АСУ ТК приведена на рисунке 1. Рисунок 1 – Архитектурная схема АСУ ТК АСУ ТК осуществляет идентификацию и авторизацию посредством ЕСИА. Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3, СМЭВ 4, а также с использованием технологий API и FTP с учетом требований Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России», утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД. АСУ ТК развернута на вычислительных мощностях Головного центра обработки данных ФБГУ «СИЦ Минтранса России». На этапе технического проектирования Подрядчик формирует требования к необходимым вычислительным мощностям для разворачивания ПО, создаваемого в рамках настоящего ТЗ. В текущей конфигурации Подсистема «Мониторинга комплексного плана» (П-МКП) обеспечивает выполнение следующих основных функций: – обеспечение оперативного взаимодействия участников реализации КПМИ в цифровой форме при подготовке, изменении и реализации планов-графиков ФП КПМИ; – визуализация содержащихся в П-МКП данных, представление их в удобном для анализа виде; – ранжирование объектов планов-графиков ФП КПМИ, в соответствии с Методикой ранжирования отдельных мероприятий, включаемых в ФП КПМИ на период до 2024 года ; – мониторинг исполнения планов-графиков ФП КПМИ, включая сбор, обработку, представление данных, необходимых для мониторинга и формирования отчетов на основе данных мониторинга планов-графиков в соответствии с Методическими указаниями по мониторингу и внесению изменений в Комплексный план модернизации и расширения магистральной инфраструктуры на период до 2024 года (транспортная часть) и ФП КПМИ - 3.2.1. Состав используемого ПО - Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. - - Значение характеристики не может изменяться участником закупки - Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ - Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ) - 3.3 Объект автоматизации в рамках настоящего Технического задания - Предметом автоматизации является объединение в едином информационном пространстве данных по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, в отношении которых предусмотрена реализация мероприятий по строительству (реконструкции) в рамках национальных и федеральных проектов. Объекты автоматизации перечислены далее - - Значение характеристики не может изменяться участником закупки - 3.3.1. Физические объекты - Объекты транспортной инфраструктуры, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – автомобильные дороги федерального, регионального, межмуниципального и местного значения; – железнодорожные пути и станции, сопутствующая инфраструктура; – аэродромы и аэропортовые комплексы; – морские и речные порты, причалы, судоходные гидротехнические сооружения. Иные объекты, относящиеся к ведению Минтранса России, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – суда, в том числе аварийно-спасательный и вспомогательный флот; – пункты пропуска через государственную границу Российской Федерации - - Значение характеристики не может изменяться участником закупки - 3.3.2. Информационные объекты - Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) - - Значение характеристики не может изменяться участником закупки - 3.3.3. Процессы автоматизации - Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных - - Значение характеристики не может изменяться участником закупки - 3.3.4. Взаимодействие участников - Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах - - Значение характеристики не может изменяться участником закупки - 4 Требования к Работам - Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы - - Значение характеристики не может изменяться участником закупки - 4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре - 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 - - Значение характеристики не может изменяться участником закупки - 17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17 - Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком. - В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей - Уровень хранения данных: – распределенные базы данных; – предзаполненный набор справочников, содержащих нормативно-справочную информацию; – отдельно вынесенный базовый функционал, обеспечивающий сохранение и обработку данных. Уровень информационного взаимодействия: – выполнение автоматизированных операций, обеспечивающих подготовку (агрегирование данных) и передачу данных между контурами. Уровень файлового хранения: – распределенная файловая система, обеспечивающая хранение и обработку загруженных в систему файлов. Уровень работы микро- и макросервисов: – запускаемые в асинхронном режиме application instance, нацеленные на выполнение отдельных ресурсоемких задач и использующие минимальный набор внутренних зависимостей, необходимых для выполнения задачи. При проектировании и разработке всех составляющих компонентов следует использовать единую методологию и единые принципы взаимодействия, надежности и управления - 4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков - № Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4 - 4.1.2 Требования к режимам функционирования П-МКП по результатам Работ - П-МКП должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования должен быть штатный. В штатном режиме все подсистемы корректно и полностью должны выполнять свои функции. Перерывов в работе как П-МКП в целом, так и одного, либо нескольких компонентов, не предусмотрено. Режим регламентного (профилактического) обслуживания должен быть предназначен для проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе П-МКП с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию П-МКП и их периодичность должны быть определены Подрядчиком в процессе выполнения работ по созданию П-МКП. В режиме регламентного (профилактического) обслуживания П-МКП может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода П-МКП в данный режим, должен быть определен Подрядчиком - - Значение характеристики не может изменяться участником закупки - Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.3 Показатели назначения - В рамках выполнения работ по развитию Системы, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице 3. Таблица 3 – Определения показателей, связанных с количеством пользователей в подсистеме «Мониторинга комплексного плана» (П-МКП) № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечивать Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения - - Значение характеристики не может изменяться участником закупки - Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице 4. Таблица 4 – Значения показателей количества пользователей подсистемы «Мониторинга комплексного плана» (П-МКП) № Показатель Значение 1 Расчетное количество пользователей 1000 2 Расчетное среднее количество одновременно работающих пользователей 500 Развитие Системы должно быть направлено на достижение следующих описаний ключевых результатов (ОКР), в рамках ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» мероприятия 1 ВПЦТ Минтранса России на период 2026-2028: · «Реализован функционал цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры подсистемы «Мониторинга комплексного плана» АСУ ТК». · «Проведено импортозамещение подсистемы «Мониторинга комплексного плана» АСУ ТК» - 4.1.4 Требования к надежности функционирования и доступности для пользователей - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надежность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счет: – обеспечения требуемого уровня квалификации обслуживающего персонала; – регламентации и нормативного обеспечения выполнения работ обслуживающего персонала; – своевременной диагностики неисправностей. Расчетное значение коэффициента готовности АСУ ТК должно составлять не менее 0,95. Планы и процессы обеспечения непрерывности функционирования АСУ ТК должны быть увязаны с перечнем наиболее критических компонентов АСУ ТК, перечнем наиболее важных информационных ресурсов АСУ ТК - - Значение характеристики не может изменяться участником закупки - ПО АСУ ТК должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов АСУ ТК; – сохранение работоспособности ПО при некорректных действиях пользователя; – резервное копирование БД Системы. Средства АСУ ТК по итогам развития должны обеспечивать следующие характеристики надежности при определенном уровне доступности функций: – операционное время: 24x7; – время восстановления работоспособности Системы после отказа или проведения регламентных работы: не более 4 часов; – отказоустойчивость на уровне 99% при единовременном обращении к Системе не менее 10 пользовательских сессий. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи публичных сетей. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Система должна автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом или исполняемых программных кодов Системы либо ее компонент) - 4.1.5 Требования по диагностированию Системы - Компоненты АСУ ТК должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО. АСУ ТК должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы. Диагностирование должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего ПО Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного ПО серверов Системы; – сбои и нарушения функционирования прикладного ПО серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в ПО диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы - - Значение характеристики не может изменяться участником закупки - 4.1.6 Требования к транспортабельности - Не предъявляются - - Значение характеристики не может изменяться участником закупки - 4.1.7 Требования к эксплуатации и техническому обслуживанию - Обслуживание Системы должно производиться обслуживающим персоналом. Допускается использование специализированных служб или подразделений на объектах внедрения для обслуживания и ремонта оборудования. При эксплуатации Системы должны использоваться штатные методы защиты от механических, тепловых, электромагнитных и других воздействий, защиты данных, в том числе, от несанкционированного доступа к ним, применяемые у Заказчика. Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Системы. При возникновении неисправностей должно осуществляться оперативное обслуживание - - Значение характеристики не может изменяться участником закупки - 4.1.8 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды - Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - - Значение характеристики не может изменяться участником закупки - 4.1.9 Требования к информационной безопасности - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего : – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - - Значение характеристики не может изменяться участником закупки - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 17, 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 20, 20.14, 25(1) и 25(2) Требований, о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11.02.2013 № 17; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.10 Требования к безопасности исходного кода - Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО - - Значение характеристики не может изменяться участником закупки - Заказчик предоставляет результаты контрольных проверок, зафиксированных в артефактах сборочного процесса, Подрядчику для устранения в срок до даты завершения исполнения Контракта. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности и т.д., в случае, если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента - 4.1.11 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов - Требования к эксплуатации оборудования Заказчик обеспечивает самостоятельно или с помощью привлеченных сторонних организаций. Для нормальной эксплуатации разрабатываемого ПО должно быть обеспечено бесперебойное питание серверов. При эксплуатации должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации серверов температура и влажность воздуха. - - Значение характеристики не может изменяться участником закупки - 4.1.12 Требования по сохранности информации при авариях - При аварийных ситуациях в АСУ ТК должна обеспечиваться сохранность информации. Реализуемые технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т. п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - - Значение характеристики не может изменяться участником закупки - 4.1.13 Требования к патентной чистоте и патентоспособности - 4.1.13.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта - - Значение характеристики не может изменяться участником закупки - 4.1.13.6. В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке) или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия – Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО; – должны передаваться исходный код, дистрибутивы, эксплуатационная и техническая документация. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности, предоставления правообладателям доступа к ПО и т.п.), не предусмотренные Контрактом - 4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1.13.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке по соответствующему этапу исполнения контракта. Разработанное ПО поставляется вместе с исходными кодами. - 4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности - 4.1.13.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.13.4. Подрядчик должен подтвердить, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части и иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними - 4.1.13.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам - 4.1.14 Требования к численности персонала оператора Системы - Дополнительные требования к численности персонала оператора не предъявляются - - Значение характеристики не может изменяться участником закупки - 4.1.15 Требования к квалификации персонала Системы, порядку его подготовки и контроля знаний и навыков - Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере, к системным администраторам предъявляются следующие требования: – знание основных принципов построения СУБД; – наличие расширенных знаний в области поддержки пользователей; – знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации - - Значение характеристики не может изменяться участником закупки - 4.1.16 Требуемый режим работы персонала оператора Системы - Режим работы персонала должен соответствовать действующему законодательству Российской Федерации (РФ) и обеспечивать работоспособность Системы согласно требованиям, предъявленным настоящим ТЗ. Должна быть учтена возможность сменного режима работы персонала Системы. При этом должна учитываться возможность круглосуточного подключения к работам специалистов, обеспечивающих функционирование Системы (администраторов и специалистов по техническому обслуживанию), для решения проблем по обеспечению работоспособности информационных ресурсов Системы - - Значение характеристики не может изменяться участником закупки - 4.1.17 Требования к эргономике и технической эстетике - Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме, возможно, системных сообщений), должны быть на русском языке. Все экранные формы должны иметь текстовую справку, в которой должна быть описана инструкция по работе с данной экранной формой. На всех экранных формах при выполнении операций должна быть выведена индикация, которая информирует пользователя о статусе выполнения операции. Система должна обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введеенных значениях - - Значение характеристики не может изменяться участником закупки - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя манипулятора типа «мышь», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов. Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских веб-интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АСУ ТК должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АСУ ТК. Визуальное представление элементов пользовательского интерфейса АСУ ТК и состав отображаемой информации подлежат согласованию Заказчиком в процессе выполнения работ по модернизации Системы - 4.2 Требования к содержанию работ 4.2.1 Архитектурное решение - 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - 4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком - 4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур. - 4.2.2 Требования к масштабируемости и расчету мощностей - 4.2.2.1 Модульность и горизонтальное масштабирование Архитектура ПО должна быть модульной и поддерживать горизонтальное масштабирование (scale-out) контуров без изменения исходного кода приложения. Функциональный контур масштабируется путем создания копий и подключения к сервису передачи агрегированных данных в информационно-аналитический контур. При этом могут применяться стратегии административного, функционального или географического разделения пользователей по экземплярам контура, в том числе с помощью настройки конфигурации приложения каждого экземпляра. Критичные компоненты, такие как серверы приложений, веб-сервисы и обработчики очередей, должны быть спроектированы как независимые, stateless (бессостоятельные, не сохраняющие состояние на самом сервере) сервисы. Хранение состояний приложения возможно с использованием СУБД. Это позволит увеличивать производительность и отказоустойчивость за счет добавления новых экземпляров сервисов в пул под нагрузкой балансировщика - - Значение характеристики не может изменяться участником закупки - 4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ - 4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов - 4.2.3 Требования к функциональным блокам информационно-аналитического контура - 4.2.3.1 АРМ Сотрудника Функциональный блок должен обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников: – сводной информации, полученной из функционального контура; – информации, сформированной в иных системах (программных продуктах) и загруженной с помощью импорта файла формата xlsx установленной структуры. Информация, собираемая и показываемая в АРМ Сотрудника, должна иметь возможность быть представленной как в рамках конкретного объекта, так и в рамках группы объектов, заданной набором фильтров. В состав данной информации должны входить показатели исполнения объекта, финансовые показатели, фиксация прохождения контрольных точек реализации исполнения. Для показа информационной сводной панели необходимо разработать функциональный блок настраиваемых аналитических панелей - компонент графического представления данных для отображения набора настраиваемых виджетов с возможностью создания (настройки) панелей для анализа информации по различным бизнес-процессам. Для формирования и выгрузки аналитических данных в форме табличного отчета необходимо разработать функциональный блок отчетности. Данный компонент должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов и достижении ключевых событий. Для сбора информации, необходимой для формирования аналитических панелей и отчетов, требуется разработать функциональный блок загрузки данных. Компонент должен обеспечивать регулярную автоматическую загрузку данных из контура функционального уровня в сводном агрегированном виде, достаточном для показа на панелях и для формирования отчетов. Кроме того, в компоненте должна быть предусмотрена возможность ручной загрузки данных в подготовленном формате - - Значение характеристики не может изменяться участником закупки - 4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта) - Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер должен представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также требуется реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания; – переход в информационный паспорт объекта во вкладке таблицы. - Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». - Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов. Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Освоено» должен отображать освоение (принято) в млн. руб. с разделением по годам, с фильтрацией по признакам: – всего нарастающим итогом с начала реализации (до утв. паспорта ФП); – всего нарастающим итогом после утверждения паспорта ФП; – всего с начала отчетного года; – всего с начала отчетного месяца; – всего по контракту/контрактам. Виджет «Контрактация» должен отображать плановый объем финансирования по контракту/ контрактам в отношении к «Законтрактовано в млн. руб» с нарастающим итогом с начала отчетного года. Необходимо реализовать фильтрацию по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Контрактация по контрактам» должен отображать сводную информацию о видах и количестве контрактов, которые были заведены. Виджет «Обеспеченность машинами и механизмами» должен отображать наличие машин и механизмов по плановому и фактическому значению в разрезе объектов. Виджет «Динамика по трудовым ресурсам (чел.), машинам и механизмам (в ед.)» должен отображать привлечение трудовых ресурсов по плану-факту с возможностью фильтрации по периоду. Виджет «Строительная готовность объекта» должен отображать готовность объекта в процентах. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Паспорт объекта должен содержать следующие вкладки: – «Паспорт» (информация и параметры объекта, участники строительства, сведения о затратах с фильтрацией по бюджетам, проблемные вопросы); – «Показатели» с возможностью редактирования; – «Финансирование» (сведения о выделенных и доведенных д\с в разбивке по бюджетам); – «Контракты» (сведения о заключенных контрактах по объекту с возможностью редактирования); – «Строительный контроль» (количество выявленных недостатков по типам; – «Подробные сведения о выявленных недостатках» с возможностью редактирования; – «Проблемные вопросы» (сведения о проблемных вопросах в разбивке по типам); – «Задачи» (доступ к функциональному блоку по работе с задачами с возможностью создания новых задач); – «Фотогалерея» (изображения с площадки строительства объекта). Необходимо реализовать виджеты, отображающие аналитическую информацию о количестве контрольных точек (далее - КТ), отражающих ход реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, относящихся к ведению Минтранса России. Все виджеты данной группы должны иметь следующие фильтры по: – национальным и федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – статусу достижения; – видам работ (проектирование, получения заключения государственной экспертизы проектной документации, строительно-монтажные работы, ввод в эксплуатацию и др.) - Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов должна раскрываться таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ. Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и их срок . Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о соблюдении ранее установленного срока, выполненных ранее срока, выполненных в срок, не выполненных в срок (срок истек), не выполненных (срок не наступил). Виджет «Контрольные точки, риски» должен отображать общее количество объектов, количество завершенных объектов, количество объектов с высокой степенью риска, со средней и умеренной/ отсутствующей. При нажатии на количество объектов должна открываться таблица с объектами и контрольными точками, отображающими текущую КТ, план и факт по каждой контрольной точке с подсвечиванием отставания соответствующим цветом. Зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев; Необходимо реализовать виджет, который отображает аналитическую информацию о текущих и прогнозных рисках и их влиянии на показатели национальных и федеральных проектов с возможностью выбора параметра (мощности), влияние на который оказывают объекты, и добавления фильтров по: – федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств - 4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.3.4 Функциональный блок загрузки данных Функциональный блок предназначен для обеспечения информационного обмена со смежным контуром и должен обеспечивать получение (загрузку) актуальных данных по проектам, объектам, их финансированию и контрольным точкам исполнения. Данные должны сохранятся в функциональном блоке в агрегированном (сводном) виде и использоваться в качестве источника информация для построения виджетов аналитической панели, а также отчетов. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных; – преобразования данных; – сохранения данных; – хранения истории запусков. Должны быть реализованы следующие стратегии загрузки: – ручная загрузка данных, предоставленных в файлах; – автоматическая загрузка данных из смежного контура. Автоматический режим подразумевает под собой фоновую регулярную загрузку сводной информации, собранной на основе актуальных данных, вводимых в функциональные блоки Ручной режим загрузки должен обеспечивать возможность загрузки данных по шаблону. Файл для загрузки должен быть в формате *xlsx. Данные могут предоставляться как в полном объеме шаблона, так и в частичном. Функция преобразования данных из файла формата xlsx должна использовать следующие стратегии: – валидация данных на соответствие шаблону; – применение функций преобразования к отдельным полям источника данных, такие как приведение типов, преобразование формата даты; – агрегация данных по выбираемым категориям; – применение функций преобразования для получения вычисляемых значений; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования - Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция хранения истории запусков должна фиксировать следующую информацию: – дата и время загрузки; – название источника; – статус загрузки; – сообщение об ошибках (при наличии). При помощи шаблона предполагается загрузка следующей сводной информации по объектам строительства: – наименование объекта строительства, федерального проекта, инвестиционного проекта, указание местоположения и пр. основные характеристики; – общая информация об объекте, включающая в себя плановые и фактические показатели с детализацией по годам за 5 лет; – плановые и фактические показатели хода реализации, описывающие сроки достижения контрольных точек этапов проектирования и строительства; – плановые финансовые показатели с детализацией по годам и источникам финансирования, включающие в себя объем финансирования и план освоения; – плановые и фактические показатели по контрактации; – плановые и фактические показатели по обеспеченности машинами и механизмами; – плановые и фактические показатели по привлечению трудовых ресурсов; – информация о строительной готовности; – информация об уровне риска реализации и необходимым мерам. Данные, переданные в функциональный блок посредством ручной загрузки отчета, должны сохраняться как в сводном виде, подходящем для показа в аналитических панелях, так и фиксироваться в виде пакета (отчета) с сохранением времени загрузки и автора - В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4 Функциональные требования к блокам функционального контура - Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов - - Значение характеристики не может изменяться участником закупки - 4.2.4.13 Функциональный блок ведения строительного контроля Необходимо разработать следующий функционал: – отражение результатов проведения инспекционной деятельности (проверки); – автоматическая генерация инспекционных документов (акт проверки и предписания) на основании зафиксированных недостатков; – работа с материалами фото и видеофиксация недостатков с возможностью сформировать отчеты о проведенных проверках и количестве выявленных недостатков; – формирование актов об устранении недостатков; – подписание актов проверки, актов инспекционного контроля, предписаний об устранении недостатков/о приостановке работ, отчета по устранению нарушений (с возможностью приложения документации, отправки отчета на почту), а также актов устранения недостатков; – формирование отчета по установленной форме; – разработка программы проведения инспекционного контроля по форме; – отображение статусов карточек документов и недостатков; – автоматическое направление участникам Проекта уведомлений о выявленных недостатках; – вызов инспектора строительного контроля на Объект (Уведомление о необходимости проведения СК на объекте оформляется на официальном бланке организации Генподрядчика. - Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; - – возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. - Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных из файлов формата xml; – преобразования данных; – сохранения данных; – фиксация выполненных действий по созданию/изменению в истории событий. Функция преобразования данных из файла формата xml должна использовать следующие стратегии: – валидация файла на соответствие xsd-схемам, утвержденным Минстроем России и опубликованным на официальном сайте как актуальные; – валидация данных файла на соответствие форматам ожидаемых данных и данным, уже имеющимся в П-МКП, в т.ч. проверка наличия и доступности пользователю объекта строительства, юридических лиц, указанных в документе. Полный набор критериев валидации должен быть разработан на этапе № 1 Календарного плана; – применение функций преобразования к отдельным полям источника данных, таким как приведение типов, преобразование формата даты; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования. Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция сохранения истории событий должна фиксировать в т.ч. следующую информацию: – дату и время события; – название события; – автора события; – сохраняемые или изменяемые данные - Данные, полученные на основании загруженного файла, должны сохраняться в качестве документов или записей, соответствующих данному документу, с фиксацией всей информации, содержащейся в файле (в т.ч. объект строительства, юридические и физические лица, информация об объемах, суммах и пр). Файл формата xml, на основании которого создан документ или запись, должен быть прикреплен к карточке этой записи и доступен для скачивания. Документы и записи, созданные посредством загрузки данных из файлов xml, должны быть доступны загрузившему их пользователю в соответствующей вкладке АРМ Подрядчика, а также сотрудникам Заказчика, имеющим доступ к объекту строительства. Функциональный блок должен поддерживать возможность загрузки файлов с измененными данными по документу (новые версии документа) с возможностью связать созданный документ с его предыдущими версиями или обновить (заменить) данные в уже существующем документе без создания новой версии. Во втором случае файл, содержащий данные об изменениях, должен быть прикреплен в качестве новой версии исходного файла. В функциональном блоке должна быть возможность разграничения прав на загрузку отдельных видов документов, определяемая настройкой прав пользователей и ролевой моделью. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи - – доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования); - 4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов - – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - № п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии - 6 Должна содержать таблицу с информацией из графика производства работ о планировании и расходовании средств и ресурсов в рамках процесса строительства. В плане должно отображаться распределение стоимостей по периодам в разрезе стоимостей или объемов работ. 7 Должна иметь возможность формирования суточного графика работ в диапазоне дат с возможностью подневного ввода фактически выполненного объема. 8 Должна быть возможность сравнения версий, имеющих связи между собой - В рамках функционального блока требуется разработать следующий набор вкладок: – список доступных Подрядчику объектов с возможностью фильтрации по общей информации об объекте (тип, вид статус, адрес объекта, участники реализации и др.) и просмотра краткой информации по каждому из них. Общий перечень данных в карточке не должен превышать описанный в разделе функциональный блок «Информация»; – вкладки с реестрами загруженных документов с возможностью группировки по типам и объектам, с возможностью перехода к карточке документа; – карточки отдельных документов, содержащие в себе основную информацию о документе и его участниках, версию документа, прикрепленный файл в формате xml, на основании которого документ был создан, список замечаний, выданных по документу, возможность выполнения действий по согласованию и подписанию с использованием функционального блока для ведения электронного документооборота (СЭД); – вкладка загрузки данных из файлов формата XML по схемам, определенным Минстроем России для передачи документов в электронном виде и опубликованным на официальном сайте; – список пользователей, являющихся представителями Подрядчика и имеющих доступ к АРМ Подрядчика и конкретным объектам в нем, с возможностью управления доступом, подключением новых пользователей и блокировкой ранее подключенных. Необходимо предусмотреть возможность для администратора от Подрядчика управлять доступом отдельных пользователей к конкретным объектам строительства; – список аккаунтов для взаимодействия с внешней системой электронного документооборота, в случае использования Удостоверяющего центра для подписания документов с использованием КЭП (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). - Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); - 4.2.4.4.3. Требования к созданию виджетов Необходимо разработать следующий функционал: – реализовать возможность точечной настройки аналитических виджетов по дате формирования данных (при необходимости); – выполнить возможность непосредственного перехода от информации на виджете дашборда к источникам данных; – реализовать возможность пользовательской настройки отображения и группировки виджетов - Необходимо разработать следующий функционал: – возможность формирования графика производства работ по проекту, в том числе на основании загруженных смет; – возможность формирования сущностей типа «запись ГПР», «Суммарная запись ГПР», «веха»; – возможность ручного добавления, удаления и перемещения по структуре работ в графике; – формирование зависимостей между работами в ГПР с установкой временных задержек; – возможность редактирования внесенного этапа работ; – назначение ответственных и исполнителей на конкретные работы графика, возможность делегирования работ; – возможность полного или частичного делегирования графика в другие версии; – возможность полуавтоматического переноса фактических показателей из делегированной версии в основную; – поддержка версионности и стадийности графиков; – возможность формирования директивной версии графика (базового плана) и заполнения новой версии ГПР на ее основании; – возможность копирования версии ГПР; – возможность сравнения связанных версий графиков между собой; – автоматический расчет критического пути с возможностью отображения только тех работ, которые принадлежат критическому пути; – автоматический расчет прогнозных сроков выполнения работ на основании динамики фактического выполнения работ; – настройка визуального отображения диаграммы Ганта; – возможность удалить этап работ из графика; - 4.2.4.4.3.5. Виджеты по тематике «Отображение аналитической информации по объектам и направлению на панели руководителя проекта» Группа виджетов должна отображать текущие показатели по объекту направления. У группы виджетов должен быть предусмотрен фильтр по направлениям (воздушный транспорт, железнодорожный транспорт, морской транспорт, речной транспорт): – стоимость контракта; – дефицит (отображает разницу между доведенными лимитами и стоимостью объекта по ССР); – непогашенный аванс (разница между суммой выданного аванса и погашенного по КС-3); – банковская гарантия с указанием даты завершения (из контрактов); – строительная готовность объекта, отображаемая в процентах, и динамика за неделю по задействованным трудовым ресурсам (чел.) и машинах и механизмах (в ед.); – характеристика объекта; – эффекты, которые оказывает объект строительства; – необходимые решения; – ход исполнения; – фотография объекта. Также по объекту из направления должна отображаться таблица с диаграммой Ганта со столбцами: – номер по порядку; – наименование объекта; – длительность (дней); – начало (дата); – окончание (дата); – диаграмма с разделением по кварталам. Виджет «Отчет по объекту» должен содержать три окна: – в первом окне – «Эффект от реализации»; – во втором окне – «Информация об объекте/Проблемные моменты» со следующим перечислением: 1) поле «Заключен ГК» (необходимо указать юридическое лицо, с которым заключен контракт), далее необходимо показать вид работ из контракта, дату заключения договора и номер контракта; 2) отображение информации о текущей контрольной точке объекта и плановой дате; 3) информация по контракту (дорожная карта); 4) дата ввода объекта в эксплуатацию с комментарием); 5) поле «Виды работ»; 6) изменения количества рабочих/техники с разбивкой по месяцам с даты начала СМР; – в третьем окне – «Предложения по решению проблем» - 4.2.4.2 АРМ Заказчика Функциональный блок АРМ Заказчика должен включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны Заказчика доступом к АРМ Подрядчика для сотрудников Подрядчиков. Функционал должен обеспечивать следующие возможности: – просмотр списка новых объектов строительства; – возможность перехода к карточке объекта, возможность добавления новых объектов; – просмотр списка юридических лиц, выступающих Подрядчиками на проектах, возможность просмотра информации о них, добавления новых, редактирования и удаления созданных ранее; – возможность создания АРМ Подрядчика для юридических лиц, выполняющих работы на объекте; – просмотр списка пользователей, являющихся представителями подрядчика, управление их доступом к АРМ Подрядчика, возможность добавления новых и блокировки неактуальных (уволенных, прекративших свою деятельность по проекту). Функциональный блок должен разрабатываться в интерфейсах, аналогичных АРМ Подрядчика. Информация представляется в виде вкладок, осуществляющих: – работу с объектами строительства; – работу и управление Подрядчиками; – настройку АРМ Подрядчика; – управление пользователями АРМ Подрядчика; – просмотр и работу с предоставленными документами через механизм загрузки в формате XML. Объем данных, выводимых в каждой вкладке, регулируется правами доступа пользователя-администратора Заказчика к объектам и юридическим лицам. Доступ к АРМ Заказчика в целом и к конкретным вкладкам в нем, должен управляться настройкой прав пользователя. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией - 4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); - 4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.4.2. Требования к отображению объекта на интерактивной схеме Функционал должен включать отображение объектов на интерактивной схеме РФ, расположенной на аналитической панели – дашборд. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта). Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также необходимо реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры); – годам; – Заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - – Виджет «Текущая аналитика СМР по ГПР» должен отображать данные по выполненным работам и освоенным средствам. Учитываются только данные из актуальных ГПР стадии СМР; – Виджет «Мониторинг исполнения ГПР, СМР» должен отображать сводную информацию о сроках исполнения плановых графиков ГПР по работам СМР (в сравнении с фактическими датами начала/окончания работ в ГПР); – Виджет «Мониторинг строительного контроля» должен отображать информацию о недостатках, выявленных в ходе проверок инспектором строительного контроля по всем объектам базы; – Виджет «Недостатки» должен отображать информацию о количестве недостатков, выявленных в ходе проверок строительного контроля в разбивке по их текущему статусу; – Виджет «Качество исполнительной документации» должен отображать количество документов, находящихся на согласовании, количество подписанных ЭП и количество выданных замечаний к документации; – Виджет «Стадии реализации (текущие)» должен отображать количество объектов по текущим стадиям реализации строительства, указанным в функциональном блоке «График производства работ» - 4.2.4.4.3.3. Виджеты по тематике «Управление проектами» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Статус объектов проектирования и строительства» должен отображать статус объектов; – Виджет «Актуальные вопросы (количество, статусы)» должен отображать количество и статусы по актуальным вопросам по объектам; – Виджет «Технико-экономические показатели реализуемых объектов» должен отображать сводную информацию об основных технико-экономических показателях объектов; – Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов раскрывается таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ; – Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и срок которых не наступил. Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о выполненных ранее срока, выполненных в срок и «Не выполнено. срок истек», «Не выполнено. Срок не наступил» - 4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам - 4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации) - Также на данном дашборде необходимо отобразить: – столбчатую горизонтальную диаграмму «Бюджетные обязательства/ Касса по годам», в которой должны отображаться данные показатели в разрезе по годам. Ниже должна быть отображена таблица с данной информацией; – столбчатую горизонтальную диаграмму «Авансы», отображающую информацию на текущий год: 1) всего аванса по контракту; 2) раскассировано аванса (сумма, которую Подрядчик может потратить со счета авансовых средств. Данные поступают от Подрядчика в виде сведений об операциях для утверждения. Источник данных – система «Электронный бюджет» (можно выгрузить в виде отчета в формате *xls); 3) выплачено аванса (фактическая сумма, перечисленная Подрядчику по выставленным им счетам. Данные поступают из бухгалтерии и также могут быть получены из «Электронного бюджета»); 4) остаток к выплате (показатель рассчитывается как разница между стоимостью контракта, выплаченного аванса и оплаты по КС-2 (актам выполненных работ); 5) зачтено аванса (часть суммы аванса, которая закрывается (засчитывается) при выполнении работ и подписании актов по КС-2 (акты выполненных работ). Таким образом, сумма к оплате по новым актам уменьшается на размер зачтенного аванса); 6) неотработанный аванс (сумма перечисленного аванса, которая еще не закрыта (не зачтена) актами выполненных работ (КС-2), то есть это разница между выплаченным авансом и суммой, которая уже была зачтена); – кольцевую диаграмму «Работы», с информацией по: 1) выполненным работам; 2) остатку к выполнению - 4.2.4.4.3.7. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по нескольким объектам из направления» Данный дашборд должен отображать таблицу «светофор» со списком всех объектов по направлениям и со следующими столбцами: – номер по порядку; – наименование объекта; – подрядчик (если договор расторгнут, то необходимо отобразить статус и дату, также если договор планируется расторгнуть или он в процессе расторжения); – стоимость объекта (млрд); – дата начала; – дата завершения; – готовность. Объекты должны быть распределены в таблице и окрашены в соответствующие цвета в зависимости от риска реализации объекта. При наличии риска реализации объекта строка с наименованием объекта должна окраситься в красный, при наличии умеренного риска - в желтый, при отсутствии риска - в зеленый). Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных - К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - – возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки) - 4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: - – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); - – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); - – строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/) - 4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9.2. Требования формированию плана освоения. Раздел функционального блока «ГПР» - вкладка «План освоения» Необходимо иметь возможность учитывать все виды ресурсов: материалы, машины и механизмы, рабочую силу, а также планировать их потребление. Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» представлены в таблице 7. Таблица 7 – Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» № п/п Функциональность вкладок 1 Должен формироваться план освоения в объемах и деньгах на основании графика работ с возможностью детализации по настраиваемым периодам распределения, настраиваемым типом расчета. В рамках плана освоения должна отображаться информация по плановым, фактическим показателям, показателям по директивному плану и закрывающим документам, а также показатели по отклонениям (план-факт, план-закрыто, факт-закрыто). 2 Должен отображаться ресурс типа -материалы. 3 Должен отображаться ресурс типа -машины и механизмы. 4 Должен отображаться ресурс типа -рабочая сила и кадры. 5 Должен позволять формировать накопительную ведомость - Также необходимо настроить систему уведомлений на почту ___@___ в системе. В уведомлении указываются сведения: 1) об объекте капитального строительства с указанием адреса (местоположения) объекта и времени проведения контрольных мероприятий; 2) о предъявляемых к освидетельствованию видов (этапов) работ, конструкций с указанием осей, пикетов, рядов, отметок или иных привязок мест расположения объекта освидетельствования и об участниках строительства, привлекаемых для выполнения указанных работ; – формирование аналитической информации по недостаткам; – отображение типовых нарушений со ссылкой на нормативные правовые акты; – замещение инспектора строительного контроля; – добавление недостатков, которые устранены в ходе проверки; – привязка недостатков к элементам BIM моделей; – привязка проверок к ПД/РД/ИД; – привязка недостатков к элементам графика производства работ; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом - 4.2.4.14 Функциональный блок ведения договоров «Управление проектом» Необходимо разработать следующий функционал: – формирование категорий контрактов; – формирование контрактов с указанием статусов, основных показателей и условий, предусмотренных контрактом (обязательства, авансы, дополнительные соглашения, гарантийные удержания и др.); – формирование и учет платежей по контрактам с привязкой к типу, план/факт, не законтрактовано (год) и типу бюджета; – формирование дополнительных соглашений к контракту с автоматическим изменением суммы, плановой даты начало/окончания контракта; – аналитика контрактов по текущим статусам, видам и типам выполняемых работ на объекте. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.8 Функциональный блок «Информация» Данный функциональный блок содержит требования к функциям ведения карточек проектов и программ. В рамках выполнения Работ необходимо организовать ввод, обмен и хранение, и актуализацию данных по проектам и программам. Карточка объекта/программы должна содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и Подрядчиков по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков). Виды информации: – общая информация об объекте строительства (тип, вид статус, адрес объекта, участники реализации и др.); – данные по освоению денежных средств (кассовое исполнение, оплачено по контрактам, риск неосвоения лимитов); – отображение всех показателей объекта (технико-экономические показатели, статус реализации, градостроительная проработка и др.); – информация по финансированию объекта (выделение и доведение денежных средств); – информация по контрактам объекта; – информация по вопросам, возникающим в ходе реализации; – данные по выполнению задач по объекту; – фотогалерея; – видеонаблюдение в режиме реального времени. При открытии карточки объекта должен открываться функциональный блок «Информация», в котором указывается сводная информация по объекту, разделенная по вкладкам согласно таблице 5 - 4.2.4.16 Функциональный блок для ведения электронного документооборота Необходимо разработать инструмент для согласования документов, связанных с реализацией проектов. Требования к разрабатываемому функционалу функционального блока «СЭД»: – работа в СЭД с такими типами документов как: письма, контракты, закупочная документация, проектная/рабочая/исполнительная документация, соглашения, отчеты, первичные документы, приказы, протоколы, распоряжения, положения, служебные/докладные/пояснительные записки, аналитические справки, доверенности. Справочник типов документов должен быть открытый и при необходимости дополняемый; – обеспечение действий Пользователя в СЭД с документами внутреннего и внешнего, документооборота: делегирование, согласование, перенаправление, многостороннее согласование, многостороннее подписание. Реализовать возможность процедуры формирования маршрутов для согласования/подписания документов; – отображение в экранной форме Пользователя в СЭД таких параметров для каждого обрабатываемого документа, как: отправитель и получатель документа, заголовок документа, дата документа, автор документа, тип и статус обрабатываемого документа, крайний срок выполнения связанной с документом задачи. Реализовать возможность фильтрации по указанным параметрам для перечня обрабатываемых Пользователем документов; – формирование документов. Реализовать возможность устанавливать взаимосвязи создаваемых документов с уже существующими в СЭД; возможность формировать приложения к письмам для различных типов файлов, размещенных в т.ч. на ПК Пользователя; поиск по наименованию/ заголовку документа в СЭД по произвольному вводу символов для существующих в СЭД документов; содержать «Тэги» для быстрого поиска созданного письма в системе; возможность указывать метки «прочитано», «не прочитано» для входящей документации; возможность настройки Пользователем на экранной форме СЭД требуемых для отображения параметров; - – наличие истории документооборота, сохраняющего записи о всех событиях и их авторах в отношении каждого документа; – интеграция СЭД с вкладкой Планировщик задач, разделом «внутрисистемная почта» и разделом «уведомления». Организация списка документов: – создание раздела «Документы» в АРМ Подрядчика в соответствии с персональными возможностями доступа пользователя к документам; – ведение списка документов с разбивкой по процессам (этапам) и статусам документа: – карточка документа – этап для формирования карточки документа; – согласование – этап для согласования карточки документа с выделением следующих статусов: 1) на согласовании (получено согласование не от всех подписантов); 2) отменено инициатором (маршрут согласования снят инициатором); 3) согласовано (всеми подписантами); 4) отказано (получен отказ хотя бы от одного подписанта); – хранение документов с завершенным или отклоненным согласованием, организованно списком записей справочника, с предоставлением в табличном или ином виде. Должна быть реализована возможность поиска по атрибутам среди документов, доступных к просмотру: – наименование документа; – тип документа; – инициатор; – по связям с сущностями. Должна быть реализована возможность фильтрации документов по атрибутам, по этапам и статусам, по признаку «Я исполнитель», «Я инициатор», «Требует действий» - Необходимо разработать следующий функционал: – автоматическое формирование плана освоения на основании сформированного графика с отображением данных, введенных в ГПР в табличной форме по различным разрезам (стоимости и объемы работ) с возможностью выбора детализации отображения по временным периодам (день / неделя / месяц / квартал / год) и типу отображения (раздельно или накопительно) и возможностью отображения различных показателей – работы / материалы / машины и механизмы / рабочая сила и кадры; – автоматическое создание плана освоения денежных средств и физических объемов выполняемых работ в разрезах рабочей силы (чел-час), ресурсов машин и механизмов (маш-час), материалов (ед. изм.); – возможность настройки отображения показателей, а также настройки диапазона дат; – формирование графика фактического освоения денежных средств и объемов по кварталам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.10 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Необходимо разработать следующий функционал: – реализация многоуровневого списка категорий документов ПИР с предустановленными значениями категорий и возможностью добавлять категории самим пользователем в случае необходимости; – наличие предустановленных шаблонов печатных форм документов «Задание на проектирование» и «Задание на инженерные изыскания», возможность выгрузить из документа в виде текстового документа; – реализация процедур согласования и подписания с помощью ЭП документов «Задание на проектирование» и «Задание на инженерные изыскания», «Программа инженерных изысканий» с отображением статуса согласования и подписания соответствующего документа; – возможность сформировать шаблон согласования и указание информации требуется ли наличие предыдущего согласования для этого уровня для выполнения процедуры согласования; – ввод, сортировка и хранение ИРД, проектной и рабочей документации в виде вложенных файлов документации ПИР; – согласование проектной документации с отображением статуса; – формирование и ведение реестров ИРД, проектной и рабочей документации; – возможность формирования документов с сохранением версий для отслеживания изменений проектной и рабочей документации; – реализация механизма работы пользователей с замечаниями к каждому отдельному документу ПИР, ДПТ; – процедура устранения замечаний исполнителем путем возможности внесения в карточку документа в разделе работы с замечаниями ответа о результатах работы над замечанием, включая прикрепления откорректированного документа (если требуется); - – формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы; - – процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта - Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий; - – просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»: - 4.2.5 Общие требования к функционированию - 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ - - Значение характеристики не может изменяться участником закупки - 4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02 - 4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы - 4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.5.3 Требования к обмену сообщениями В рамках выполнения Работ реализуется встроенный мессенджер, позволяющий обмениваться сообщениями между пользователями АРМ. Требования к разрабатываемому функционалу: – создание персональных чатов из списка пользователей из раздела мессенджера; – создание групповых чатов из раздела мессенджера; – возможность отправки текстовых сообщений и файлов; – поиск по списку чатов; – возможность удаления созданного чата; – корректировка перечня участников группового чата; – индикация групповых чатов в списке - 4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования - 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления - - Значение характеристики не может изменяться участником закупки - 4.3.5 Требования по применению систем управления хранилищами и базами данных Для хранения данных должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – наличие сертификата соответствия ФСТЭК России требованиям по защите информации, предъявляемым к системам управления базами данных не ниже 5 класса защиты; – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов - 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологической в инфраструктуре Заказчика. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика. 2) Допускается использование только кластеризованных баз данных. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре Заказчика. 3) Решение должно быть отказоустойчивым. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов. 4) Любые соединения, устанавливаемые решением, должны быть защищенными*. Примечания: 1 Защищенные соединения, выходящие за пределы контролируемой зоны, должны быть защищены с помощью программных и/или программно-аппаратных шифровальных (криптографических) средств, сертифицированных ФСБ России (далее – СКЗИ). 2 Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД; 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. Использование учетных записей с административными полномочиями не допускается - 4.3.2 Требования к организации хранилища данных Для хранения информации должна использоваться СУБД с возможностями распределенного хранения данных по кластерным узлам. СУБД предоставляется Заказчиком после завершения этапа № 1 Календарного плана. Структура БД должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в БД Системы. При проектировании структуры БД для хранения данных необходимо провести анализ реализованной структуры БД для П-МКП в целях использования в создаваемых АРМ. В результате анализа Подрядчик обязан представить Заказчику в Пояснительной записке описание структуры БД для функционирования АРМ с указанием переиспользуемых и вновь создаваемых таблиц БД. Информация должна размещаться в БД по возможности в нормализованной форме. Допускается использование дополнительных ненормализованных структур данных для повышения производительности. Допускается размещение отдельных параметров конфигурации во внешних конфигурационных файлах. Допускается размещение данных в нереляционных СУБД в случаях, предусматривающих очевидную выгоду в производительности, оптимизации требуемого места для хранения данных или необходимых вычислительных ресурсах по согласованию с Заказчиком. Полный перечень используемых программных решений должен быть определен Подрядчиком и согласован Заказчиком на этапе № 1 Календарного плана - 4.3.4 Требования к информационному обмену между компонентами Системы Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет - 5 Состав и содержание работ по развитию АСУ ТК - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) - - Значение характеристики не может изменяться участником закупки - 5.1 Состав работ и график их выполнения (календарный план) - 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 - - Значение характеристики не может изменяться участником закупки - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Сроки, установленные Календарным планом для каждого подпункта в рамках этапов, согласно таблице 11, включают подготовку, согласование, утверждение (для тех документов, в отношении которых требуется согласование или утверждение) отчетных, технических, рабочих документов с Заказчиком. Досрочная сдача результатов допускается по согласованию с Заказчиком. Сокращение периода (длительности) проведения опытной эксплуатации недопустимо. График выполнения работ по развитию АСУ ТК приведен в таблице 11. Таблица 11 – График выполнения работ по развитию АСУ ТК - № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа Ожидаемые результаты работ 1 Техническое проектирование. 1.1. Разработка частного технического задания Начало: с даты заключения контракта Окончание: не позднее 19.01.2026 Сопроводительным письмом предоставлены Заказчику: Частное техническое задание. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 1.2. Разработка технического проекта Начало: 19.01.2026 Окончание: не позднее 26.01.2026 Сопроводительным письмом предоставлены Заказчику: Технический проект в составе: - Описание архитектуры системы; - Пояснительная записка, включая описание автоматизируемых функций; - Описание программного обеспечения; - Описание информационного обеспечения; - Ведомость технического проекта; - Ведомость машинных носителей информации; - Руководство по безопасной разработке программного обеспечения. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу) - 2 Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Сопроводительным письмом предоставлены Заказчику: Исходные коды разработанного (передаваемого) программного обеспечения; Дистрибутивы разработанного (передаваемого) программного обеспечение; Инструкция по сборке; Паспорт П-МКП; Описание П-МКП; Руководство администратора; Руководства пользователей на каждый АРМ, включая рекомендуемые характеристики к ПК для АРМ; Документы по испытаниям в составе: - Программа и методика предварительных испытаний; - Протокол предварительных испытаний; - Программа и методика опытной эксплуатации; - Акт ввода в опытную эксплуатацию; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 - 3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026 - 6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации - Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ - - Значение характеристики не может изменяться участником закупки - 6.2 Виды, состав, объем и методы испытаний и его составных частей - В случае выявления ошибок в ПО П-МКП при проведении предварительных испытаний, Подрядчик должен их устранить до начала момента проведения опытной эксплуатации. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки). Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены Подрядчиком в документе «Программа и методика опытной эксплуатации». Программа и методика опытной эксплуатации должна быть утверждена Заказчиком до проведения опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» (с приложением журнала опытной эксплуатации) и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации, подтверждающий готовность П-МКП АСУ ТК и ее допуск к приемочным испытаниям - - Значение характеристики не может изменяться участником закупки - Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный - Результаты проведения предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от ТЗ оформляются как недостатки работ. Прочие недостатки могут документироваться как рекомендации. Наличие рекомендаций не влияет на процесс передачи П-МКП АСУ ТК в эксплуатацию. В случае значительного отклонения П-МКП АСУ ТК от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены или расширены Заказчиком. По результатам выполнения этапа № 3 должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии и сроки проведения испытаний. Испытания проводятся на площадке, указанной в программе и методике соответствующих испытаний, опытной эксплуатации. В состав комиссии включаются ответственные лица Заказчика и Подрядчика, а также, при необходимости, специалисты иных внешних организаций (например, экспертных), привлекаемые Заказчиком. Подрядчик обязан уведомить Заказчика о готовности к проведению испытаний официальным сопроводительным письмом и предоставить Заказчику программу и методику испытаний (далее – ПМИ). Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком и Подрядчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытаний и Акт о приемке в опытную эксплуатацию, подтверждающий готовность П-МКП АСУ ТК к следующему виду испытаний – опытной эксплуатации - Состав мероприятий, включенных в пилотную зону, может быть изменен по согласованию с заказчиком. В случае выявления ошибок в ПО П-МКП при проведении опытной эксплуатации, Подрядчик должен их устранить до начала приемочных испытаний. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки) Методы приемочных испытаний и порядок их проведения должны быть определены в документе «Программа и методика приемочных испытаний», который должен быть подготовлен Подрядчиком и утвержден Заказчиком до начала приемочных испытаний. По результатам проведения приемочных испытаний оформляются Протокол приемочных испытаний и Акт готовности П-МКП к эксплуатации. В Протоколе приемочных испытаний должны быть указаны перечень проверяемых сервисов, функций, возможностей, дата и время проведения приемочных испытаний, состав приемочной комиссии, рекомендации (при наличии) к решению, а также выводы о готовности П-МКП АСУ ТК к вводу в эксплуатацию. Ввод П-МКП АСУ ТК в эксплуатацию осуществляется после выполнения работ по ИБ, подписанием соответствующего акта - 6.3 Порядок контроля и приемки выполненных работ - Сдача-приемка выполненных работ осуществляется в соответствии с условиями Контракта. Сдача-приемка работ осуществляется по завершении каждого этапа в порядке, установленном в Контракте - - Значение характеристики не может изменяться участником закупки - 6.3.1 Условия о порядке предоставления (передачи) результатов выполнения работ Заказчику - Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ, а также в соответствии с инструкциями, приведенными в рабочей документации на П-МКП. Документация на П-МКП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - - Значение характеристики не может изменяться участником закупки - Передача исходных кодов, разработанных и/или передаваемых в ходе выполнения работ программ для электронных вычислительных машин (далее - программа для ЭВМ) и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных и/или передаваемых в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает заказчику исходные коды, дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения. - 6.4 Сведения о гарантийном обслуживании - Гарантийный срок: один год с даты подписания Заказчиком документа о приемке Этапа № 3. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, включая замечания и комментарии от федеральных органов исполнительной власти в области обеспечения безопасности, федерального органа исполнительной власти, уполномоченного в области противодействия техническим разведкам и технической защиты информации, Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерства транспорта Российской Федерации и Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций, выявленных после приемки выполненных Работ, в том числе в документации, разработанной по результатам выполненных Работ, касающиеся соответствия требованиям нормативных правовых актов, действующих на момент завершения этапа № 2. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, установленные Заказчиком в Акте с перечнем выявленных недостатков. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Гарантийным случаем признается полное или частичное отсутствие функционирования П-МКП и ее компонентов в результате выполнения работ по настоящему Техническому заданию. Подрядчик должен обеспечить гарантию работоспособности П-МКП, включая гарантийную поддержку - - Значение характеристики не может изменяться участником закупки - В рамках гарантийной поддержки П-МКП Подрядчик должен: – устранять обнаруженные в процессе постоянной эксплуатации дефекты в работе П-МКП в срок не более 5-ти рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); – принимать участие в восстановлении работоспособности П-МКП после сбоев и аварий, вызванных дефектами и недокументированными возможностями подсистемы, выполняя при этом работы, связанные с восстановлением целостности данных и обновлением П-МКП; – вносить изменения в техническую и рабочую документацию на функциональные блоки, на основании выявленных неточностей или обнаруженных недокументированных возможностей подсистемы; – консультировать представителей Заказчика об особенностях реализации П-МКП, в том числе при установке, настройке и пуско-наладке Системы; – давать ответ на заявку Заказчика в течение 1 (Одного) рабочего дня с момента ее поступления - 7 Источники разработки - Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки - Приложение А к Техническому заданию - Таблица А.1 – Описание состава загружаемых данных по мероприятиям Раздел данных Подраздел данных Название атрибута Общая информация об объекте - Наименование Федерального проекта - Инвестпроект - Участок - Длина участка, км Провозная способность, млн. тонн в год план факт Пропускная способность, пар поездов в сутки план факт Максимальная весовая норма поездов, тонн план факт - Наименование мероприятия/объекта - Код объекта - Ответственный исполнитель/ заказчик (контакты) - Субъект Российской Федерации/фактическое (местоположение объекта) - Код ИП - Назначение объекта, основные характеристики объекта (ТЭП) - Предварительная стоимость по ФП (млн. руб.) Ход реализации (Проектирование) Заключен контракт на инженерные изыскания ПД план факт Направление ПД на ГГЭ план по условиям договора факт Получение заключения государственной экспертизы на ПСД план по условиям договора факт стоимость по итогам заключения ФАУ «Главгосэкспертиза России» - Сроки по ПОС Ход реализации (Строительство) Проведение конкурсных процедур на выполнение СМР Объявление торгов (план) Объявление торгов (факт) Заключение контракта на СМР (план) Заключение контракта на СМР (факт) Оформление земельно-правовых отношений* план факт выполнение в % Получено РС план факт Ввод объекта во временную эксплуатацию план факт Получен ЗОС план факт Ввод объекта в эксплуатацию (РВ) план по условиям договора* факт отклонение (дни) - Примечание Обеспеченность машинами и механизмами - план факт - - Строительная готовность (в %) Привлечение трудовых ресурсов, чел. - план факт - - Уровень риска реализации (определяется по наличию отставаний по контрольным точкам, влияющих на срок ввода в эксплуатацию) Объем финансирования в соответствии с ФП (млн. руб.) Год, по которому сформирован отчет Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Сводная бюджетная роспись на отчетную дату - - Значение характеристики не может изменяться участником закупки - Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) - Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства

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

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

ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик»)

1 Общие сведения 1.1 Наименование системы - Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. - - Значение характеристики не может изменяться участником закупки

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

1.3 Основания для выполнения работ - 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; - - Значение характеристики не может изменяться участником закупки

10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010;

17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ - 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации - - Значение характеристики не может изменяться участником закупки

1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия»

11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»;

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

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

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

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

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

2.2 Цели развития Системы - Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

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

2.3 Состав выполняемых задач - Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей

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

3.2 Текущее состояние объекта автоматизации - АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи - - Значение характеристики не может изменяться участником закупки

1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП

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

3.2.1. Состав используемого ПО - Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. - - Значение характеристики не может изменяться участником закупки

Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ

Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ)

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

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

3.3.2. Информационные объекты - Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) - - Значение характеристики не может изменяться участником закупки

3.3.3. Процессы автоматизации - Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных - - Значение характеристики не может изменяться участником закупки

3.3.4. Взаимодействие участников - Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах - - Значение характеристики не может изменяться участником закупки

4 Требования к Работам - Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы - - Значение характеристики не может изменяться участником закупки

4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре - 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 - - Значение характеристики не может изменяться участником закупки

17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17

Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком.

В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей

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

4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков

№ Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4

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

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

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

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

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

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

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

4.1.6 Требования к транспортабельности - Не предъявляются - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.1.10 Требования к безопасности исходного кода - Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО - - Значение характеристики не может изменяться участником закупки

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

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

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

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

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

4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности

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

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

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

4.1.14 Требования к численности персонала оператора Системы - Дополнительные требования к численности персонала оператора не предъявляются - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.2 Требования к содержанию работ 4.2.1 Архитектурное решение - 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком

4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур.

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

4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ

4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов

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

4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта)

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

Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации».

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

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

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

4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4 Функциональные требования к блокам функционального контура - Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов - - Значение характеристики не может изменяться участником закупки

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

Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа;

– возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных.

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

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

4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи

– доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования);

4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов

– журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

№ п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии

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

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

Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/);

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

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

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

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

4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией

4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР);

4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

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

4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам

4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации)

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

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

4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных

К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

– возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки)

4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов:

– исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/);

– журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/);

– строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/)

4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом

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

4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

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

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

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

– формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы;

– процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта

Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий;

– просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»:

4.2.5 Общие требования к функционированию - 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ - - Значение характеристики не может изменяться участником закупки

4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02

4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы

4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования - 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления - - Значение характеристики не может изменяться участником закупки

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

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

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

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

5 Состав и содержание работ по развитию АСУ ТК - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) - - Значение характеристики не может изменяться участником закупки

5.1 Состав работ и график их выполнения (календарный план) - 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 - - Значение характеристики не может изменяться участником закупки

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

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

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

3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026

6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации - Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ - - Значение характеристики не может изменяться участником закупки

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

Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный

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

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

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

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

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

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

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

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

7 Источники разработки - Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки

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

Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.)

Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства

- 62.01.11.000 - Этап №2: Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект ... 1 Общие сведения 1.1 Наименование системы Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. 1.2 Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры - Условная единица - 1,00 - 174 809 300,15 - 174 809 300,15

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект Значение характеристики не может изменяться участником закупки ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») 1 Общие сведения 1.1 Наименование системы Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. Значение характеристики не может изменяться участником закупки 1.2 Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры Значение характеристики не может изменяться участником закупки 1.3 Основания для выполнения работ 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; Значение характеристики не может изменяться участником закупки 10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010; 17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» Значение характеристики не может изменяться участником закупки 11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»; 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 30.06.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего ТЗ (далее – Календарный план) Значение характеристики не может изменяться участником закупки 1.6 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5.1 настоящего ТЗ, в соответствии с Календарным планом и Контрактом Значение характеристики не может изменяться участником закупки 1.7 Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет. Тестовый стенд для проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний предоставляет Заказчик. Доступ к тестовому стенду Заказчик предоставляет Подрядчику на основании письменного обращения. Требования к предоставляемым вычислительным мощностям должны соответствовать требованиям, указанным в пояснительной записке, представляемой на этапе № 1 работ Значение характеристики не может изменяться участником закупки 2 Назначение и цели развития Системы 2.1 Назначение Системы Основными задачами, решаемыми в настоящий момент системой АСУ ТК, являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов контроля безопасности и устойчивости транспортного комплекса, управления в чрезвычайных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими органами государственной власти, а также гражданами и организациями Значение характеристики не может изменяться участником закупки АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными стратегическими целями развития АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и принятия мер по их устранению и ликвидации последствий 2.2 Цели развития Системы Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки Основными целями выполнения работ являются: – создание среды взаимодействия участников строительства на этапах реализации процесса строительства (реконструкции); – создание единого источника достоверной, непротиворечивой и верифицированной информации для принятия решений на всех управленческих уровнях; – повышение достоверности и прозрачности информации об инвестиционных проектах и программах; – повышение дисциплины формирования и предоставления плановых и отчетных форм; – обеспечение единого информационного пространства инструментам регистрации, хранения, согласования документов-обоснований; – обеспечение инструментов контроля полной стоимости, статей затрат по базовым, текущим ценам и ценам инвестиционного проекта, и физическим характеристикам; – обеспечение формирования графиков, контроля исполнения и сигнализация рисков неисполнения контрольных этапов; – повышение прозрачности процессов и оптимизация взаимодействия между различными участниками реализации инвестиционных проектов. Достижение указанных целей осуществляется для достижения стратегических целей развития АСУ ТК, указанных в пункте 2.1 ТЗ. Основные процессы, автоматизируемые в рамках выполнения Работ: – управление инвестиционными проектами строительства и реконструкции; – управление разработкой и согласование ПИР на всех стадиях реализации проекта; – управление задачами участников проектов строительства и реконструкции; – формирование и согласование исполнительной документации; – формирование и ведение календарно-сетевого планирования; – проведение процедуры строительного контроля; – формирование отчетности 2.3 Состав выполняемых задач Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей 3 Сведения об объектах автоматизации 3.1 Описание объектов автоматизации Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими органами государственной власти, гражданами и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. В соответствии с Аттестатом соответствия требованиям по защите информации АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Значение характеристики не может изменяться участником закупки 3.2 Текущее состояние объекта автоматизации Текущая архитектура АСУ ТК приведена на рисунке 1. Рисунок 1 – Архитектурная схема АСУ ТК АСУ ТК осуществляет идентификацию и авторизацию посредством ЕСИА. Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3, СМЭВ 4, а также с использованием технологий API и FTP с учетом требований Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России», утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД. АСУ ТК развернута на вычислительных мощностях Головного центра обработки данных ФБГУ «СИЦ Минтранса России». На этапе технического проектирования Подрядчик формирует требования к необходимым вычислительным мощностям для разворачивания ПО, создаваемого в рамках настоящего ТЗ. В текущей конфигурации Подсистема «Мониторинга комплексного плана» (П-МКП) обеспечивает выполнение следующих основных функций: – обеспечение оперативного взаимодействия участников реализации КПМИ в цифровой форме при подготовке, изменении и реализации планов-графиков ФП КПМИ; – визуализация содержащихся в П-МКП данных, представление их в удобном для анализа виде; – ранжирование объектов планов-графиков ФП КПМИ, в соответствии с Методикой ранжирования отдельных мероприятий, включаемых в ФП КПМИ на период до 2024 года ; – мониторинг исполнения планов-графиков ФП КПМИ, включая сбор, обработку, представление данных, необходимых для мониторинга и формирования отчетов на основе данных мониторинга планов-графиков в соответствии с Методическими указаниями по мониторингу и внесению изменений в Комплексный план модернизации и расширения магистральной инфраструктуры на период до 2024 года (транспортная часть) и ФП КПМИ Значение характеристики не может изменяться участником закупки АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи 1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП 3.2.1. Состав используемого ПО Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Значение характеристики не может изменяться участником закупки Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ) 3.3 Объект автоматизации в рамках настоящего Технического задания Предметом автоматизации является объединение в едином информационном пространстве данных по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, в отношении которых предусмотрена реализация мероприятий по строительству (реконструкции) в рамках национальных и федеральных проектов. Объекты автоматизации перечислены далее Значение характеристики не может изменяться участником закупки 3.3.1. Физические объекты Объекты транспортной инфраструктуры, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – автомобильные дороги федерального, регионального, межмуниципального и местного значения; – железнодорожные пути и станции, сопутствующая инфраструктура; – аэродромы и аэропортовые комплексы; – морские и речные порты, причалы, судоходные гидротехнические сооружения. Иные объекты, относящиеся к ведению Минтранса России, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – суда, в том числе аварийно-спасательный и вспомогательный флот; – пункты пропуска через государственную границу Российской Федерации Значение характеристики не может изменяться участником закупки 3.3.2. Информационные объекты Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) Значение характеристики не может изменяться участником закупки 3.3.3. Процессы автоматизации Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных Значение характеристики не может изменяться участником закупки 3.3.4. Взаимодействие участников Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах Значение характеристики не может изменяться участником закупки 4 Требования к Работам Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы Значение характеристики не может изменяться участником закупки 4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 Значение характеристики не может изменяться участником закупки 17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17 Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком. В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей Уровень хранения данных: – распределенные базы данных; – предзаполненный набор справочников, содержащих нормативно-справочную информацию; – отдельно вынесенный базовый функционал, обеспечивающий сохранение и обработку данных. Уровень информационного взаимодействия: – выполнение автоматизированных операций, обеспечивающих подготовку (агрегирование данных) и передачу данных между контурами. Уровень файлового хранения: – распределенная файловая система, обеспечивающая хранение и обработку загруженных в систему файлов. Уровень работы микро- и макросервисов: – запускаемые в асинхронном режиме application instance, нацеленные на выполнение отдельных ресурсоемких задач и использующие минимальный набор внутренних зависимостей, необходимых для выполнения задачи. При проектировании и разработке всех составляющих компонентов следует использовать единую методологию и единые принципы взаимодействия, надежности и управления 4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков № Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4 4.1.2 Требования к режимам функционирования П-МКП по результатам Работ П-МКП должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования должен быть штатный. В штатном режиме все подсистемы корректно и полностью должны выполнять свои функции. Перерывов в работе как П-МКП в целом, так и одного, либо нескольких компонентов, не предусмотрено. Режим регламентного (профилактического) обслуживания должен быть предназначен для проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе П-МКП с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию П-МКП и их периодичность должны быть определены Подрядчиком в процессе выполнения работ по созданию П-МКП. В режиме регламентного (профилактического) обслуживания П-МКП может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода П-МКП в данный режим, должен быть определен Подрядчиком Значение характеристики не может изменяться участником закупки Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.3 Показатели назначения В рамках выполнения работ по развитию Системы, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице 3. Таблица 3 – Определения показателей, связанных с количеством пользователей в подсистеме «Мониторинга комплексного плана» (П-МКП) № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечивать Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значение характеристики не может изменяться участником закупки Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице 4. Таблица 4 – Значения показателей количества пользователей подсистемы «Мониторинга комплексного плана» (П-МКП) № Показатель Значение 1 Расчетное количество пользователей 1000 2 Расчетное среднее количество одновременно работающих пользователей 500 Развитие Системы должно быть направлено на достижение следующих описаний ключевых результатов (ОКР), в рамках ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» мероприятия 1 ВПЦТ Минтранса России на период 2026-2028: · «Реализован функционал цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры подсистемы «Мониторинга комплексного плана» АСУ ТК». · «Проведено импортозамещение подсистемы «Мониторинга комплексного плана» АСУ ТК» 4.1.4 Требования к надежности функционирования и доступности для пользователей Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надежность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счет: – обеспечения требуемого уровня квалификации обслуживающего персонала; – регламентации и нормативного обеспечения выполнения работ обслуживающего персонала; – своевременной диагностики неисправностей. Расчетное значение коэффициента готовности АСУ ТК должно составлять не менее 0,95. Планы и процессы обеспечения непрерывности функционирования АСУ ТК должны быть увязаны с перечнем наиболее критических компонентов АСУ ТК, перечнем наиболее важных информационных ресурсов АСУ ТК Значение характеристики не может изменяться участником закупки ПО АСУ ТК должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов АСУ ТК; – сохранение работоспособности ПО при некорректных действиях пользователя; – резервное копирование БД Системы. Средства АСУ ТК по итогам развития должны обеспечивать следующие характеристики надежности при определенном уровне доступности функций: – операционное время: 24x7; – время восстановления работоспособности Системы после отказа или проведения регламентных работы: не более 4 часов; – отказоустойчивость на уровне 99% при единовременном обращении к Системе не менее 10 пользовательских сессий. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи публичных сетей. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Система должна автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом или исполняемых программных кодов Системы либо ее компонент) 4.1.5 Требования по диагностированию Системы Компоненты АСУ ТК должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО. АСУ ТК должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы. Диагностирование должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего ПО Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного ПО серверов Системы; – сбои и нарушения функционирования прикладного ПО серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в ПО диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы Значение характеристики не может изменяться участником закупки 4.1.6 Требования к транспортабельности Не предъявляются Значение характеристики не может изменяться участником закупки 4.1.7 Требования к эксплуатации и техническому обслуживанию Обслуживание Системы должно производиться обслуживающим персоналом. Допускается использование специализированных служб или подразделений на объектах внедрения для обслуживания и ремонта оборудования. При эксплуатации Системы должны использоваться штатные методы защиты от механических, тепловых, электромагнитных и других воздействий, защиты данных, в том числе, от несанкционированного доступа к ним, применяемые у Заказчика. Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Системы. При возникновении неисправностей должно осуществляться оперативное обслуживание Значение характеристики не может изменяться участником закупки 4.1.8 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется Значение характеристики не может изменяться участником закупки 4.1.9 Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего : – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; Значение характеристики не может изменяться участником закупки – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 17, 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 20, 20.14, 25(1) и 25(2) Требований, о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11.02.2013 № 17; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.10 Требования к безопасности исходного кода Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО Значение характеристики не может изменяться участником закупки Заказчик предоставляет результаты контрольных проверок, зафиксированных в артефактах сборочного процесса, Подрядчику для устранения в срок до даты завершения исполнения Контракта. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности и т.д., в случае, если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента 4.1.11 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Требования к эксплуатации оборудования Заказчик обеспечивает самостоятельно или с помощью привлеченных сторонних организаций. Для нормальной эксплуатации разрабатываемого ПО должно быть обеспечено бесперебойное питание серверов. При эксплуатации должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации серверов температура и влажность воздуха. Значение характеристики не может изменяться участником закупки 4.1.12 Требования по сохранности информации при авариях При аварийных ситуациях в АСУ ТК должна обеспечиваться сохранность информации. Реализуемые технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т. п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными Значение характеристики не может изменяться участником закупки 4.1.13 Требования к патентной чистоте и патентоспособности 4.1.13.6. В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке) или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия – Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО; – должны передаваться исходный код, дистрибутивы, эксплуатационная и техническая документация. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности, предоставления правообладателям доступа к ПО и т.п.), не предусмотренные Контрактом Значение характеристики не может изменяться участником закупки 4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1.13.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке по соответствующему этапу исполнения контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности 4.1.13.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.13.4. Подрядчик должен подтвердить, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части и иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними 4.1.13.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам 4.1.13.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта 4.1.14 Требования к численности персонала оператора Системы Дополнительные требования к численности персонала оператора не предъявляются Значение характеристики не может изменяться участником закупки 4.1.15 Требования к квалификации персонала Системы, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере, к системным администраторам предъявляются следующие требования: – знание основных принципов построения СУБД; – наличие расширенных знаний в области поддержки пользователей; – знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации Значение характеристики не может изменяться участником закупки 4.1.16 Требуемый режим работы персонала оператора Системы Режим работы персонала должен соответствовать действующему законодательству Российской Федерации (РФ) и обеспечивать работоспособность Системы согласно требованиям, предъявленным настоящим ТЗ. Должна быть учтена возможность сменного режима работы персонала Системы. При этом должна учитываться возможность круглосуточного подключения к работам специалистов, обеспечивающих функционирование Системы (администраторов и специалистов по техническому обслуживанию), для решения проблем по обеспечению работоспособности информационных ресурсов Системы Значение характеристики не может изменяться участником закупки 4.1.17 Требования к эргономике и технической эстетике Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя манипулятора типа «мышь», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов. Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских веб-интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АСУ ТК должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АСУ ТК. Визуальное представление элементов пользовательского интерфейса АСУ ТК и состав отображаемой информации подлежат согласованию Заказчиком в процессе выполнения работ по модернизации Системы Значение характеристики не может изменяться участником закупки Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме, возможно, системных сообщений), должны быть на русском языке. Все экранные формы должны иметь текстовую справку, в которой должна быть описана инструкция по работе с данной экранной формой. На всех экранных формах при выполнении операций должна быть выведена индикация, которая информирует пользователя о статусе выполнения операции. Система должна обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введеенных значениях 4.2 Требования к содержанию работ 4.2.1 Архитектурное решение 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки 4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком 4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур. 4.2.2 Требования к масштабируемости и расчету мощностей 4.2.2.1 Модульность и горизонтальное масштабирование Архитектура ПО должна быть модульной и поддерживать горизонтальное масштабирование (scale-out) контуров без изменения исходного кода приложения. Функциональный контур масштабируется путем создания копий и подключения к сервису передачи агрегированных данных в информационно-аналитический контур. При этом могут применяться стратегии административного, функционального или географического разделения пользователей по экземплярам контура, в том числе с помощью настройки конфигурации приложения каждого экземпляра. Критичные компоненты, такие как серверы приложений, веб-сервисы и обработчики очередей, должны быть спроектированы как независимые, stateless (бессостоятельные, не сохраняющие состояние на самом сервере) сервисы. Хранение состояний приложения возможно с использованием СУБД. Это позволит увеличивать производительность и отказоустойчивость за счет добавления новых экземпляров сервисов в пул под нагрузкой балансировщика Значение характеристики не может изменяться участником закупки 4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ 4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов 4.2.3 Требования к функциональным блокам информационно-аналитического контура 4.2.3.1 АРМ Сотрудника Функциональный блок должен обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников: – сводной информации, полученной из функционального контура; – информации, сформированной в иных системах (программных продуктах) и загруженной с помощью импорта файла формата xlsx установленной структуры. Информация, собираемая и показываемая в АРМ Сотрудника, должна иметь возможность быть представленной как в рамках конкретного объекта, так и в рамках группы объектов, заданной набором фильтров. В состав данной информации должны входить показатели исполнения объекта, финансовые показатели, фиксация прохождения контрольных точек реализации исполнения. Для показа информационной сводной панели необходимо разработать функциональный блок настраиваемых аналитических панелей - компонент графического представления данных для отображения набора настраиваемых виджетов с возможностью создания (настройки) панелей для анализа информации по различным бизнес-процессам. Для формирования и выгрузки аналитических данных в форме табличного отчета необходимо разработать функциональный блок отчетности. Данный компонент должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов и достижении ключевых событий. Для сбора информации, необходимой для формирования аналитических панелей и отчетов, требуется разработать функциональный блок загрузки данных. Компонент должен обеспечивать регулярную автоматическую загрузку данных из контура функционального уровня в сводном агрегированном виде, достаточном для показа на панелях и для формирования отчетов. Кроме того, в компоненте должна быть предусмотрена возможность ручной загрузки данных в подготовленном формате Значение характеристики не может изменяться участником закупки 4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта) Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер должен представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также требуется реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания; – переход в информационный паспорт объекта во вкладке таблицы. Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов. Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Освоено» должен отображать освоение (принято) в млн. руб. с разделением по годам, с фильтрацией по признакам: – всего нарастающим итогом с начала реализации (до утв. паспорта ФП); – всего нарастающим итогом после утверждения паспорта ФП; – всего с начала отчетного года; – всего с начала отчетного месяца; – всего по контракту/контрактам. Виджет «Контрактация» должен отображать плановый объем финансирования по контракту/ контрактам в отношении к «Законтрактовано в млн. руб» с нарастающим итогом с начала отчетного года. Необходимо реализовать фильтрацию по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Контрактация по контрактам» должен отображать сводную информацию о видах и количестве контрактов, которые были заведены. Виджет «Обеспеченность машинами и механизмами» должен отображать наличие машин и механизмов по плановому и фактическому значению в разрезе объектов. Виджет «Динамика по трудовым ресурсам (чел.), машинам и механизмам (в ед.)» должен отображать привлечение трудовых ресурсов по плану-факту с возможностью фильтрации по периоду. Виджет «Строительная готовность объекта» должен отображать готовность объекта в процентах. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Паспорт объекта должен содержать следующие вкладки: – «Паспорт» (информация и параметры объекта, участники строительства, сведения о затратах с фильтрацией по бюджетам, проблемные вопросы); – «Показатели» с возможностью редактирования; – «Финансирование» (сведения о выделенных и доведенных д\с в разбивке по бюджетам); – «Контракты» (сведения о заключенных контрактах по объекту с возможностью редактирования); – «Строительный контроль» (количество выявленных недостатков по типам; – «Подробные сведения о выявленных недостатках» с возможностью редактирования; – «Проблемные вопросы» (сведения о проблемных вопросах в разбивке по типам); – «Задачи» (доступ к функциональному блоку по работе с задачами с возможностью создания новых задач); – «Фотогалерея» (изображения с площадки строительства объекта). Необходимо реализовать виджеты, отображающие аналитическую информацию о количестве контрольных точек (далее - КТ), отражающих ход реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, относящихся к ведению Минтранса России. Все виджеты данной группы должны иметь следующие фильтры по: – национальным и федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – статусу достижения; – видам работ (проектирование, получения заключения государственной экспертизы проектной документации, строительно-монтажные работы, ввод в эксплуатацию и др.) Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов должна раскрываться таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ. Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и их срок . Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о соблюдении ранее установленного срока, выполненных ранее срока, выполненных в срок, не выполненных в срок (срок истек), не выполненных (срок не наступил). Виджет «Контрольные точки, риски» должен отображать общее количество объектов, количество завершенных объектов, количество объектов с высокой степенью риска, со средней и умеренной/ отсутствующей. При нажатии на количество объектов должна открываться таблица с объектами и контрольными точками, отображающими текущую КТ, план и факт по каждой контрольной точке с подсвечиванием отставания соответствующим цветом. Зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев; Необходимо реализовать виджет, который отображает аналитическую информацию о текущих и прогнозных рисках и их влиянии на показатели национальных и федеральных проектов с возможностью выбора параметра (мощности), влияние на который оказывают объекты, и добавления фильтров по: – федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств 4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.3.4 Функциональный блок загрузки данных Функциональный блок предназначен для обеспечения информационного обмена со смежным контуром и должен обеспечивать получение (загрузку) актуальных данных по проектам, объектам, их финансированию и контрольным точкам исполнения. Данные должны сохранятся в функциональном блоке в агрегированном (сводном) виде и использоваться в качестве источника информация для построения виджетов аналитической панели, а также отчетов. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных; – преобразования данных; – сохранения данных; – хранения истории запусков. Должны быть реализованы следующие стратегии загрузки: – ручная загрузка данных, предоставленных в файлах; – автоматическая загрузка данных из смежного контура. Автоматический режим подразумевает под собой фоновую регулярную загрузку сводной информации, собранной на основе актуальных данных, вводимых в функциональные блоки Ручной режим загрузки должен обеспечивать возможность загрузки данных по шаблону. Файл для загрузки должен быть в формате *xlsx. Данные могут предоставляться как в полном объеме шаблона, так и в частичном. Функция преобразования данных из файла формата xlsx должна использовать следующие стратегии: – валидация данных на соответствие шаблону; – применение функций преобразования к отдельным полям источника данных, такие как приведение типов, преобразование формата даты; – агрегация данных по выбираемым категориям; – применение функций преобразования для получения вычисляемых значений; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция хранения истории запусков должна фиксировать следующую информацию: – дата и время загрузки; – название источника; – статус загрузки; – сообщение об ошибках (при наличии). При помощи шаблона предполагается загрузка следующей сводной информации по объектам строительства: – наименование объекта строительства, федерального проекта, инвестиционного проекта, указание местоположения и пр. основные характеристики; – общая информация об объекте, включающая в себя плановые и фактические показатели с детализацией по годам за 5 лет; – плановые и фактические показатели хода реализации, описывающие сроки достижения контрольных точек этапов проектирования и строительства; – плановые финансовые показатели с детализацией по годам и источникам финансирования, включающие в себя объем финансирования и план освоения; – плановые и фактические показатели по контрактации; – плановые и фактические показатели по обеспеченности машинами и механизмами; – плановые и фактические показатели по привлечению трудовых ресурсов; – информация о строительной готовности; – информация об уровне риска реализации и необходимым мерам. Данные, переданные в функциональный блок посредством ручной загрузки отчета, должны сохраняться как в сводном виде, подходящем для показа в аналитических панелях, так и фиксироваться в виде пакета (отчета) с сохранением времени загрузки и автора В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4 Функциональные требования к блокам функционального контура Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; Значение характеристики не может изменяться участником закупки – возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Необходимо разработать следующий функционал: – возможность формирования графика производства работ по проекту, в том числе на основании загруженных смет; – возможность формирования сущностей типа «запись ГПР», «Суммарная запись ГПР», «веха»; – возможность ручного добавления, удаления и перемещения по структуре работ в графике; – формирование зависимостей между работами в ГПР с установкой временных задержек; – возможность редактирования внесенного этапа работ; – назначение ответственных и исполнителей на конкретные работы графика, возможность делегирования работ; – возможность полного или частичного делегирования графика в другие версии; – возможность полуавтоматического переноса фактических показателей из делегированной версии в основную; – поддержка версионности и стадийности графиков; – возможность формирования директивной версии графика (базового плана) и заполнения новой версии ГПР на ее основании; – возможность копирования версии ГПР; – возможность сравнения связанных версий графиков между собой; – автоматический расчет критического пути с возможностью отображения только тех работ, которые принадлежат критическому пути; – автоматический расчет прогнозных сроков выполнения работ на основании динамики фактического выполнения работ; – настройка визуального отображения диаграммы Ганта; – возможность удалить этап работ из графика; 4.2.4.4.3.5. Виджеты по тематике «Отображение аналитической информации по объектам и направлению на панели руководителя проекта» Группа виджетов должна отображать текущие показатели по объекту направления. У группы виджетов должен быть предусмотрен фильтр по направлениям (воздушный транспорт, железнодорожный транспорт, морской транспорт, речной транспорт): – стоимость контракта; – дефицит (отображает разницу между доведенными лимитами и стоимостью объекта по ССР); – непогашенный аванс (разница между суммой выданного аванса и погашенного по КС-3); – банковская гарантия с указанием даты завершения (из контрактов); – строительная готовность объекта, отображаемая в процентах, и динамика за неделю по задействованным трудовым ресурсам (чел.) и машинах и механизмах (в ед.); – характеристика объекта; – эффекты, которые оказывает объект строительства; – необходимые решения; – ход исполнения; – фотография объекта. Также по объекту из направления должна отображаться таблица с диаграммой Ганта со столбцами: – номер по порядку; – наименование объекта; – длительность (дней); – начало (дата); – окончание (дата); – диаграмма с разделением по кварталам. Виджет «Отчет по объекту» должен содержать три окна: – в первом окне – «Эффект от реализации»; – во втором окне – «Информация об объекте/Проблемные моменты» со следующим перечислением: 1) поле «Заключен ГК» (необходимо указать юридическое лицо, с которым заключен контракт), далее необходимо показать вид работ из контракта, дату заключения договора и номер контракта; 2) отображение информации о текущей контрольной точке объекта и плановой дате; 3) информация по контракту (дорожная карта); 4) дата ввода объекта в эксплуатацию с комментарием); 5) поле «Виды работ»; 6) изменения количества рабочих/техники с разбивкой по месяцам с даты начала СМР; – в третьем окне – «Предложения по решению проблем» 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных из файлов формата xml; – преобразования данных; – сохранения данных; – фиксация выполненных действий по созданию/изменению в истории событий. Функция преобразования данных из файла формата xml должна использовать следующие стратегии: – валидация файла на соответствие xsd-схемам, утвержденным Минстроем России и опубликованным на официальном сайте как актуальные; – валидация данных файла на соответствие форматам ожидаемых данных и данным, уже имеющимся в П-МКП, в т.ч. проверка наличия и доступности пользователю объекта строительства, юридических лиц, указанных в документе. Полный набор критериев валидации должен быть разработан на этапе № 1 Календарного плана; – применение функций преобразования к отдельным полям источника данных, таким как приведение типов, преобразование формата даты; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования. Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция сохранения истории событий должна фиксировать в т.ч. следующую информацию: – дату и время события; – название события; – автора события; – сохраняемые или изменяемые данные Данные, полученные на основании загруженного файла, должны сохраняться в качестве документов или записей, соответствующих данному документу, с фиксацией всей информации, содержащейся в файле (в т.ч. объект строительства, юридические и физические лица, информация об объемах, суммах и пр). Файл формата xml, на основании которого создан документ или запись, должен быть прикреплен к карточке этой записи и доступен для скачивания. Документы и записи, созданные посредством загрузки данных из файлов xml, должны быть доступны загрузившему их пользователю в соответствующей вкладке АРМ Подрядчика, а также сотрудникам Заказчика, имеющим доступ к объекту строительства. Функциональный блок должен поддерживать возможность загрузки файлов с измененными данными по документу (новые версии документа) с возможностью связать созданный документ с его предыдущими версиями или обновить (заменить) данные в уже существующем документе без создания новой версии. Во втором случае файл, содержащий данные об изменениях, должен быть прикреплен в качестве новой версии исходного файла. В функциональном блоке должна быть возможность разграничения прав на загрузку отдельных видов документов, определяемая настройкой прав пользователей и ролевой моделью. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов В рамках функционального блока требуется разработать следующий набор вкладок: – список доступных Подрядчику объектов с возможностью фильтрации по общей информации об объекте (тип, вид статус, адрес объекта, участники реализации и др.) и просмотра краткой информации по каждому из них. Общий перечень данных в карточке не должен превышать описанный в разделе функциональный блок «Информация»; – вкладки с реестрами загруженных документов с возможностью группировки по типам и объектам, с возможностью перехода к карточке документа; – карточки отдельных документов, содержащие в себе основную информацию о документе и его участниках, версию документа, прикрепленный файл в формате xml, на основании которого документ был создан, список замечаний, выданных по документу, возможность выполнения действий по согласованию и подписанию с использованием функционального блока для ведения электронного документооборота (СЭД); – вкладка загрузки данных из файлов формата XML по схемам, определенным Минстроем России для передачи документов в электронном виде и опубликованным на официальном сайте; – список пользователей, являющихся представителями Подрядчика и имеющих доступ к АРМ Подрядчика и конкретным объектам в нем, с возможностью управления доступом, подключением новых пользователей и блокировкой ранее подключенных. Необходимо предусмотреть возможность для администратора от Подрядчика управлять доступом отдельных пользователей к конкретным объектам строительства; – список аккаунтов для взаимодействия с внешней системой электронного документооборота, в случае использования Удостоверяющего центра для подписания документов с использованием КЭП (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); 4.2.4.4.3. Требования к созданию виджетов Необходимо разработать следующий функционал: – реализовать возможность точечной настройки аналитических виджетов по дате формирования данных (при необходимости); – выполнить возможность непосредственного перехода от информации на виджете дашборда к источникам данных; – реализовать возможность пользовательской настройки отображения и группировки виджетов 4.2.4.2 АРМ Заказчика Функциональный блок АРМ Заказчика должен включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны Заказчика доступом к АРМ Подрядчика для сотрудников Подрядчиков. Функционал должен обеспечивать следующие возможности: – просмотр списка новых объектов строительства; – возможность перехода к карточке объекта, возможность добавления новых объектов; – просмотр списка юридических лиц, выступающих Подрядчиками на проектах, возможность просмотра информации о них, добавления новых, редактирования и удаления созданных ранее; – возможность создания АРМ Подрядчика для юридических лиц, выполняющих работы на объекте; – просмотр списка пользователей, являющихся представителями подрядчика, управление их доступом к АРМ Подрядчика, возможность добавления новых и блокировки неактуальных (уволенных, прекративших свою деятельность по проекту). Функциональный блок должен разрабатываться в интерфейсах, аналогичных АРМ Подрядчика. Информация представляется в виде вкладок, осуществляющих: – работу с объектами строительства; – работу и управление Подрядчиками; – настройку АРМ Подрядчика; – управление пользователями АРМ Подрядчика; – просмотр и работу с предоставленными документами через механизм загрузки в формате XML. Объем данных, выводимых в каждой вкладке, регулируется правами доступа пользователя-администратора Заказчика к объектам и юридическим лицам. Доступ к АРМ Заказчика в целом и к конкретным вкладкам в нем, должен управляться настройкой прав пользователя. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией 4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.4.2. Требования к отображению объекта на интерактивной схеме Функционал должен включать отображение объектов на интерактивной схеме РФ, расположенной на аналитической панели – дашборд. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта). Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также необходимо реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры); – годам; – Заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана – Виджет «Текущая аналитика СМР по ГПР» должен отображать данные по выполненным работам и освоенным средствам. Учитываются только данные из актуальных ГПР стадии СМР; – Виджет «Мониторинг исполнения ГПР, СМР» должен отображать сводную информацию о сроках исполнения плановых графиков ГПР по работам СМР (в сравнении с фактическими датами начала/окончания работ в ГПР); – Виджет «Мониторинг строительного контроля» должен отображать информацию о недостатках, выявленных в ходе проверок инспектором строительного контроля по всем объектам базы; – Виджет «Недостатки» должен отображать информацию о количестве недостатков, выявленных в ходе проверок строительного контроля в разбивке по их текущему статусу; – Виджет «Качество исполнительной документации» должен отображать количество документов, находящихся на согласовании, количество подписанных ЭП и количество выданных замечаний к документации; – Виджет «Стадии реализации (текущие)» должен отображать количество объектов по текущим стадиям реализации строительства, указанным в функциональном блоке «График производства работ» 4.2.4.4.3.3. Виджеты по тематике «Управление проектами» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Статус объектов проектирования и строительства» должен отображать статус объектов; – Виджет «Актуальные вопросы (количество, статусы)» должен отображать количество и статусы по актуальным вопросам по объектам; – Виджет «Технико-экономические показатели реализуемых объектов» должен отображать сводную информацию об основных технико-экономических показателях объектов; – Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов раскрывается таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ; – Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и срок которых не наступил. Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о выполненных ранее срока, выполненных в срок и «Не выполнено. срок истек», «Не выполнено. Срок не наступил» 4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам 4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана – возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки) 4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации) Также на данном дашборде необходимо отобразить: – столбчатую горизонтальную диаграмму «Бюджетные обязательства/ Касса по годам», в которой должны отображаться данные показатели в разрезе по годам. Ниже должна быть отображена таблица с данной информацией; – столбчатую горизонтальную диаграмму «Авансы», отображающую информацию на текущий год: 1) всего аванса по контракту; 2) раскассировано аванса (сумма, которую Подрядчик может потратить со счета авансовых средств. Данные поступают от Подрядчика в виде сведений об операциях для утверждения. Источник данных – система «Электронный бюджет» (можно выгрузить в виде отчета в формате *xls); 3) выплачено аванса (фактическая сумма, перечисленная Подрядчику по выставленным им счетам. Данные поступают из бухгалтерии и также могут быть получены из «Электронного бюджета»); 4) остаток к выплате (показатель рассчитывается как разница между стоимостью контракта, выплаченного аванса и оплаты по КС-2 (актам выполненных работ); 5) зачтено аванса (часть суммы аванса, которая закрывается (засчитывается) при выполнении работ и подписании актов по КС-2 (акты выполненных работ). Таким образом, сумма к оплате по новым актам уменьшается на размер зачтенного аванса); 6) неотработанный аванс (сумма перечисленного аванса, которая еще не закрыта (не зачтена) актами выполненных работ (КС-2), то есть это разница между выплаченным авансом и суммой, которая уже была зачтена); – кольцевую диаграмму «Работы», с информацией по: 1) выполненным работам; 2) остатку к выполнению 4.2.4.4.3.7. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по нескольким объектам из направления» Данный дашборд должен отображать таблицу «светофор» со списком всех объектов по направлениям и со следующими столбцами: – номер по порядку; – наименование объекта; – подрядчик (если договор расторгнут, то необходимо отобразить статус и дату, также если договор планируется расторгнуть или он в процессе расторжения); – стоимость объекта (млрд); – дата начала; – дата завершения; – готовность. Объекты должны быть распределены в таблице и окрашены в соответствующие цвета в зависимости от риска реализации объекта. При наличии риска реализации объекта строка с наименованием объекта должна окраситься в красный, при наличии умеренного риска - в желтый, при отсутствии риска - в зеленый). Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9.2. Требования формированию плана освоения. Раздел функционального блока «ГПР» - вкладка «План освоения» Необходимо иметь возможность учитывать все виды ресурсов: материалы, машины и механизмы, рабочую силу, а также планировать их потребление. Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» представлены в таблице 7. Таблица 7 – Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» № п/п Функциональность вкладок 1 Должен формироваться план освоения в объемах и деньгах на основании графика работ с возможностью детализации по настраиваемым периодам распределения, настраиваемым типом расчета. В рамках плана освоения должна отображаться информация по плановым, фактическим показателям, показателям по директивному плану и закрывающим документам, а также показатели по отклонениям (план-факт, план-закрыто, факт-закрыто). 2 Должен отображаться ресурс типа -материалы. 3 Должен отображаться ресурс типа -машины и механизмы. 4 Должен отображаться ресурс типа -рабочая сила и кадры. 5 Должен позволять формировать накопительную ведомость Также необходимо настроить систему уведомлений на почту ___@___ в системе. В уведомлении указываются сведения: 1) об объекте капитального строительства с указанием адреса (местоположения) объекта и времени проведения контрольных мероприятий; 2) о предъявляемых к освидетельствованию видов (этапов) работ, конструкций с указанием осей, пикетов, рядов, отметок или иных привязок мест расположения объекта освидетельствования и об участниках строительства, привлекаемых для выполнения указанных работ; – формирование аналитической информации по недостаткам; – отображение типовых нарушений со ссылкой на нормативные правовые акты; – замещение инспектора строительного контроля; – добавление недостатков, которые устранены в ходе проверки; – привязка недостатков к элементам BIM моделей; – привязка проверок к ПД/РД/ИД; – привязка недостатков к элементам графика производства работ; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/) 4.2.4.14 Функциональный блок ведения договоров «Управление проектом» Необходимо разработать следующий функционал: – формирование категорий контрактов; – формирование контрактов с указанием статусов, основных показателей и условий, предусмотренных контрактом (обязательства, авансы, дополнительные соглашения, гарантийные удержания и др.); – формирование и учет платежей по контрактам с привязкой к типу, план/факт, не законтрактовано (год) и типу бюджета; – формирование дополнительных соглашений к контракту с автоматическим изменением суммы, плановой даты начало/окончания контракта; – аналитика контрактов по текущим статусам, видам и типам выполняемых работ на объекте. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.8 Функциональный блок «Информация» Данный функциональный блок содержит требования к функциям ведения карточек проектов и программ. В рамках выполнения Работ необходимо организовать ввод, обмен и хранение, и актуализацию данных по проектам и программам. Карточка объекта/программы должна содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и Подрядчиков по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков). Виды информации: – общая информация об объекте строительства (тип, вид статус, адрес объекта, участники реализации и др.); – данные по освоению денежных средств (кассовое исполнение, оплачено по контрактам, риск неосвоения лимитов); – отображение всех показателей объекта (технико-экономические показатели, статус реализации, градостроительная проработка и др.); – информация по финансированию объекта (выделение и доведение денежных средств); – информация по контрактам объекта; – информация по вопросам, возникающим в ходе реализации; – данные по выполнению задач по объекту; – фотогалерея; – видеонаблюдение в режиме реального времени. При открытии карточки объекта должен открываться функциональный блок «Информация», в котором указывается сводная информация по объекту, разделенная по вкладкам согласно таблице 5 Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом Необходимо разработать следующий функционал: – автоматическое формирование плана освоения на основании сформированного графика с отображением данных, введенных в ГПР в табличной форме по различным разрезам (стоимости и объемы работ) с возможностью выбора детализации отображения по временным периодам (день / неделя / месяц / квартал / год) и типу отображения (раздельно или накопительно) и возможностью отображения различных показателей – работы / материалы / машины и механизмы / рабочая сила и кадры; – автоматическое создание плана освоения денежных средств и физических объемов выполняемых работ в разрезах рабочей силы (чел-час), ресурсов машин и механизмов (маш-час), материалов (ед. изм.); – возможность настройки отображения показателей, а также настройки диапазона дат; – формирование графика фактического освоения денежных средств и объемов по кварталам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.10 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Необходимо разработать следующий функционал: – реализация многоуровневого списка категорий документов ПИР с предустановленными значениями категорий и возможностью добавлять категории самим пользователем в случае необходимости; – наличие предустановленных шаблонов печатных форм документов «Задание на проектирование» и «Задание на инженерные изыскания», возможность выгрузить из документа в виде текстового документа; – реализация процедур согласования и подписания с помощью ЭП документов «Задание на проектирование» и «Задание на инженерные изыскания», «Программа инженерных изысканий» с отображением статуса согласования и подписания соответствующего документа; – возможность сформировать шаблон согласования и указание информации требуется ли наличие предыдущего согласования для этого уровня для выполнения процедуры согласования; – ввод, сортировка и хранение ИРД, проектной и рабочей документации в виде вложенных файлов документации ПИР; – согласование проектной документации с отображением статуса; – формирование и ведение реестров ИРД, проектной и рабочей документации; – возможность формирования документов с сохранением версий для отслеживания изменений проектной и рабочей документации; – реализация механизма работы пользователей с замечаниями к каждому отдельному документу ПИР, ДПТ; – процедура устранения замечаний исполнителем путем возможности внесения в карточку документа в разделе работы с замечаниями ответа о результатах работы над замечанием, включая прикрепления откорректированного документа (если требуется); 4.2.4.16 Функциональный блок для ведения электронного документооборота Необходимо разработать инструмент для согласования документов, связанных с реализацией проектов. Требования к разрабатываемому функционалу функционального блока «СЭД»: – работа в СЭД с такими типами документов как: письма, контракты, закупочная документация, проектная/рабочая/исполнительная документация, соглашения, отчеты, первичные документы, приказы, протоколы, распоряжения, положения, служебные/докладные/пояснительные записки, аналитические справки, доверенности. Справочник типов документов должен быть открытый и при необходимости дополняемый; – обеспечение действий Пользователя в СЭД с документами внутреннего и внешнего, документооборота: делегирование, согласование, перенаправление, многостороннее согласование, многостороннее подписание. Реализовать возможность процедуры формирования маршрутов для согласования/подписания документов; – отображение в экранной форме Пользователя в СЭД таких параметров для каждого обрабатываемого документа, как: отправитель и получатель документа, заголовок документа, дата документа, автор документа, тип и статус обрабатываемого документа, крайний срок выполнения связанной с документом задачи. Реализовать возможность фильтрации по указанным параметрам для перечня обрабатываемых Пользователем документов; – формирование документов. Реализовать возможность устанавливать взаимосвязи создаваемых документов с уже существующими в СЭД; возможность формировать приложения к письмам для различных типов файлов, размещенных в т.ч. на ПК Пользователя; поиск по наименованию/ заголовку документа в СЭД по произвольному вводу символов для существующих в СЭД документов; содержать «Тэги» для быстрого поиска созданного письма в системе; возможность указывать метки «прочитано», «не прочитано» для входящей документации; возможность настройки Пользователем на экранной форме СЭД требуемых для отображения параметров; – наличие истории документооборота, сохраняющего записи о всех событиях и их авторах в отношении каждого документа; – интеграция СЭД с вкладкой Планировщик задач, разделом «внутрисистемная почта» и разделом «уведомления». Организация списка документов: – создание раздела «Документы» в АРМ Подрядчика в соответствии с персональными возможностями доступа пользователя к документам; – ведение списка документов с разбивкой по процессам (этапам) и статусам документа: – карточка документа – этап для формирования карточки документа; – согласование – этап для согласования карточки документа с выделением следующих статусов: 1) на согласовании (получено согласование не от всех подписантов); 2) отменено инициатором (маршрут согласования снят инициатором); 3) согласовано (всеми подписантами); 4) отказано (получен отказ хотя бы от одного подписанта); – хранение документов с завершенным или отклоненным согласованием, организованно списком записей справочника, с предоставлением в табличном или ином виде. Должна быть реализована возможность поиска по атрибутам среди документов, доступных к просмотру: – наименование документа; – тип документа; – инициатор; – по связям с сущностями. Должна быть реализована возможность фильтрации документов по атрибутам, по этапам и статусам, по признаку «Я исполнитель», «Я инициатор», «Требует действий» – формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы; – процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий; – просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»: 4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи – доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования); Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов 4.2.4.13 Функциональный блок ведения строительного контроля Необходимо разработать следующий функционал: – отражение результатов проведения инспекционной деятельности (проверки); – автоматическая генерация инспекционных документов (акт проверки и предписания) на основании зафиксированных недостатков; – работа с материалами фото и видеофиксация недостатков с возможностью сформировать отчеты о проведенных проверках и количестве выявленных недостатков; – формирование актов об устранении недостатков; – подписание актов проверки, актов инспекционного контроля, предписаний об устранении недостатков/о приостановке работ, отчета по устранению нарушений (с возможностью приложения документации, отправки отчета на почту), а также актов устранения недостатков; – формирование отчета по установленной форме; – разработка программы проведения инспекционного контроля по форме; – отображение статусов карточек документов и недостатков; – автоматическое направление участникам Проекта уведомлений о выявленных недостатках; – вызов инспектора строительного контроля на Объект (Уведомление о необходимости проведения СК на объекте оформляется на официальном бланке организации Генподрядчика. – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана № п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии 6 Должна содержать таблицу с информацией из графика производства работ о планировании и расходовании средств и ресурсов в рамках процесса строительства. В плане должно отображаться распределение стоимостей по периодам в разрезе стоимостей или объемов работ. 7 Должна иметь возможность формирования суточного графика работ в диапазоне дат с возможностью подневного ввода фактически выполненного объема. 8 Должна быть возможность сравнения версий, имеющих связи между собой 4.2.5 Общие требования к функционированию 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ Значение характеристики не может изменяться участником закупки 4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02 4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы 4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.5.3 Требования к обмену сообщениями В рамках выполнения Работ реализуется встроенный мессенджер, позволяющий обмениваться сообщениями между пользователями АРМ. Требования к разрабатываемому функционалу: – создание персональных чатов из списка пользователей из раздела мессенджера; – создание групповых чатов из раздела мессенджера; – возможность отправки текстовых сообщений и файлов; – поиск по списку чатов; – возможность удаления созданного чата; – корректировка перечня участников группового чата; – индикация групповых чатов в списке 4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления Значение характеристики не может изменяться участником закупки 4.3.5 Требования по применению систем управления хранилищами и базами данных Для хранения данных должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – наличие сертификата соответствия ФСТЭК России требованиям по защите информации, предъявляемым к системам управления базами данных не ниже 5 класса защиты; – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологической в инфраструктуре Заказчика. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика. 2) Допускается использование только кластеризованных баз данных. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре Заказчика. 3) Решение должно быть отказоустойчивым. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов. 4) Любые соединения, устанавливаемые решением, должны быть защищенными*. Примечания: 1 Защищенные соединения, выходящие за пределы контролируемой зоны, должны быть защищены с помощью программных и/или программно-аппаратных шифровальных (криптографических) средств, сертифицированных ФСБ России (далее – СКЗИ). 2 Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД; 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. Использование учетных записей с административными полномочиями не допускается 4.3.2 Требования к организации хранилища данных Для хранения информации должна использоваться СУБД с возможностями распределенного хранения данных по кластерным узлам. СУБД предоставляется Заказчиком после завершения этапа № 1 Календарного плана. Структура БД должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в БД Системы. При проектировании структуры БД для хранения данных необходимо провести анализ реализованной структуры БД для П-МКП в целях использования в создаваемых АРМ. В результате анализа Подрядчик обязан представить Заказчику в Пояснительной записке описание структуры БД для функционирования АРМ с указанием переиспользуемых и вновь создаваемых таблиц БД. Информация должна размещаться в БД по возможности в нормализованной форме. Допускается использование дополнительных ненормализованных структур данных для повышения производительности. Допускается размещение отдельных параметров конфигурации во внешних конфигурационных файлах. Допускается размещение данных в нереляционных СУБД в случаях, предусматривающих очевидную выгоду в производительности, оптимизации требуемого места для хранения данных или необходимых вычислительных ресурсах по согласованию с Заказчиком. Полный перечень используемых программных решений должен быть определен Подрядчиком и согласован Заказчиком на этапе № 1 Календарного плана 4.3.4 Требования к информационному обмену между компонентами Системы Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет 5 Состав и содержание работ по развитию АСУ ТК В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) Значение характеристики не может изменяться участником закупки 5.1 Состав работ и график их выполнения (календарный план) 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 Значение характеристики не может изменяться участником закупки Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Сроки, установленные Календарным планом для каждого подпункта в рамках этапов, согласно таблице 11, включают подготовку, согласование, утверждение (для тех документов, в отношении которых требуется согласование или утверждение) отчетных, технических, рабочих документов с Заказчиком. Досрочная сдача результатов допускается по согласованию с Заказчиком. Сокращение периода (длительности) проведения опытной эксплуатации недопустимо. График выполнения работ по развитию АСУ ТК приведен в таблице 11. Таблица 11 – График выполнения работ по развитию АСУ ТК № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа Ожидаемые результаты работ 1 Техническое проектирование. 1.1. Разработка частного технического задания Начало: с даты заключения контракта Окончание: не позднее 19.01.2026 Сопроводительным письмом предоставлены Заказчику: Частное техническое задание. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 1.2. Разработка технического проекта Начало: 19.01.2026 Окончание: не позднее 26.01.2026 Сопроводительным письмом предоставлены Заказчику: Технический проект в составе: - Описание архитектуры системы; - Пояснительная записка, включая описание автоматизируемых функций; - Описание программного обеспечения; - Описание информационного обеспечения; - Ведомость технического проекта; - Ведомость машинных носителей информации; - Руководство по безопасной разработке программного обеспечения. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу) 2 Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Сопроводительным письмом предоставлены Заказчику: Исходные коды разработанного (передаваемого) программного обеспечения; Дистрибутивы разработанного (передаваемого) программного обеспечение; Инструкция по сборке; Паспорт П-МКП; Описание П-МКП; Руководство администратора; Руководства пользователей на каждый АРМ, включая рекомендуемые характеристики к ПК для АРМ; Документы по испытаниям в составе: - Программа и методика предварительных испытаний; - Протокол предварительных испытаний; - Программа и методика опытной эксплуатации; - Акт ввода в опытную эксплуатацию; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026 6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ Значение характеристики не может изменяться участником закупки 6.2 Виды, состав, объем и методы испытаний и его составных частей В случае выявления ошибок в ПО П-МКП при проведении предварительных испытаний, Подрядчик должен их устранить до начала момента проведения опытной эксплуатации. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки). Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены Подрядчиком в документе «Программа и методика опытной эксплуатации». Программа и методика опытной эксплуатации должна быть утверждена Заказчиком до проведения опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» (с приложением журнала опытной эксплуатации) и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации, подтверждающий готовность П-МКП АСУ ТК и ее допуск к приемочным испытаниям Значение характеристики не может изменяться участником закупки Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный Результаты проведения предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от ТЗ оформляются как недостатки работ. Прочие недостатки могут документироваться как рекомендации. Наличие рекомендаций не влияет на процесс передачи П-МКП АСУ ТК в эксплуатацию. В случае значительного отклонения П-МКП АСУ ТК от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены или расширены Заказчиком. По результатам выполнения этапа № 3 должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии и сроки проведения испытаний. Испытания проводятся на площадке, указанной в программе и методике соответствующих испытаний, опытной эксплуатации. В состав комиссии включаются ответственные лица Заказчика и Подрядчика, а также, при необходимости, специалисты иных внешних организаций (например, экспертных), привлекаемые Заказчиком. Подрядчик обязан уведомить Заказчика о готовности к проведению испытаний официальным сопроводительным письмом и предоставить Заказчику программу и методику испытаний (далее – ПМИ). Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком и Подрядчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытаний и Акт о приемке в опытную эксплуатацию, подтверждающий готовность П-МКП АСУ ТК к следующему виду испытаний – опытной эксплуатации Состав мероприятий, включенных в пилотную зону, может быть изменен по согласованию с заказчиком. В случае выявления ошибок в ПО П-МКП при проведении опытной эксплуатации, Подрядчик должен их устранить до начала приемочных испытаний. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки) Методы приемочных испытаний и порядок их проведения должны быть определены в документе «Программа и методика приемочных испытаний», который должен быть подготовлен Подрядчиком и утвержден Заказчиком до начала приемочных испытаний. По результатам проведения приемочных испытаний оформляются Протокол приемочных испытаний и Акт готовности П-МКП к эксплуатации. В Протоколе приемочных испытаний должны быть указаны перечень проверяемых сервисов, функций, возможностей, дата и время проведения приемочных испытаний, состав приемочной комиссии, рекомендации (при наличии) к решению, а также выводы о готовности П-МКП АСУ ТК к вводу в эксплуатацию. Ввод П-МКП АСУ ТК в эксплуатацию осуществляется после выполнения работ по ИБ, подписанием соответствующего акта 6.3 Порядок контроля и приемки выполненных работ Сдача-приемка выполненных работ осуществляется в соответствии с условиями Контракта. Сдача-приемка работ осуществляется по завершении каждого этапа в порядке, установленном в Контракте Значение характеристики не может изменяться участником закупки 6.3.1 Условия о порядке предоставления (передачи) результатов выполнения работ Заказчику Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ, а также в соответствии с инструкциями, приведенными в рабочей документации на П-МКП. Документация на П-МКП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика Значение характеристики не может изменяться участником закупки Передача исходных кодов, разработанных и/или передаваемых в ходе выполнения работ программ для электронных вычислительных машин (далее - программа для ЭВМ) и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных и/или передаваемых в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает заказчику исходные коды, дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения. 6.4 Сведения о гарантийном обслуживании Гарантийный срок: один год с даты подписания Заказчиком документа о приемке Этапа № 3. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, включая замечания и комментарии от федеральных органов исполнительной власти в области обеспечения безопасности, федерального органа исполнительной власти, уполномоченного в области противодействия техническим разведкам и технической защиты информации, Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерства транспорта Российской Федерации и Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций, выявленных после приемки выполненных Работ, в том числе в документации, разработанной по результатам выполненных Работ, касающиеся соответствия требованиям нормативных правовых актов, действующих на момент завершения этапа № 2. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, установленные Заказчиком в Акте с перечнем выявленных недостатков. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Гарантийным случаем признается полное или частичное отсутствие функционирования П-МКП и ее компонентов в результате выполнения работ по настоящему Техническому заданию. Подрядчик должен обеспечить гарантию работоспособности П-МКП, включая гарантийную поддержку Значение характеристики не может изменяться участником закупки В рамках гарантийной поддержки П-МКП Подрядчик должен: – устранять обнаруженные в процессе постоянной эксплуатации дефекты в работе П-МКП в срок не более 5-ти рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); – принимать участие в восстановлении работоспособности П-МКП после сбоев и аварий, вызванных дефектами и недокументированными возможностями подсистемы, выполняя при этом работы, связанные с восстановлением целостности данных и обновлением П-МКП; – вносить изменения в техническую и рабочую документацию на функциональные блоки, на основании выявленных неточностей или обнаруженных недокументированных возможностей подсистемы; – консультировать представителей Заказчика об особенностях реализации П-МКП, в том числе при установке, настройке и пуско-наладке Системы; – давать ответ на заявку Заказчика в течение 1 (Одного) рабочего дня с момента ее поступления 7 Источники разработки Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» Значение характеристики не может изменяться участником закупки Приложение А к Техническому заданию Таблица А.1 – Описание состава загружаемых данных по мероприятиям Раздел данных Подраздел данных Название атрибута Общая информация об объекте - Наименование Федерального проекта - Инвестпроект - Участок - Длина участка, км Провозная способность, млн. тонн в год план факт Пропускная способность, пар поездов в сутки план факт Максимальная весовая норма поездов, тонн план факт - Наименование мероприятия/объекта - Код объекта - Ответственный исполнитель/ заказчик (контакты) - Субъект Российской Федерации/фактическое (местоположение объекта) - Код ИП - Назначение объекта, основные характеристики объекта (ТЭП) - Предварительная стоимость по ФП (млн. руб.) Ход реализации (Проектирование) Заключен контракт на инженерные изыскания ПД план факт Направление ПД на ГГЭ план по условиям договора факт Получение заключения государственной экспертизы на ПСД план по условиям договора факт стоимость по итогам заключения ФАУ «Главгосэкспертиза России» - Сроки по ПОС Ход реализации (Строительство) Проведение конкурсных процедур на выполнение СМР Объявление торгов (план) Объявление торгов (факт) Заключение контракта на СМР (план) Заключение контракта на СМР (факт) Оформление земельно-правовых отношений* план факт выполнение в % Получено РС план факт Ввод объекта во временную эксплуатацию план факт Получен ЗОС план факт Ввод объекта в эксплуатацию (РВ) план по условиям договора* факт отклонение (дни) - Примечание Обеспеченность машинами и механизмами - план факт - - Строительная готовность (в %) Привлечение трудовых ресурсов, чел. - план факт - - Уровень риска реализации (определяется по наличию отставаний по контрольным точкам, влияющих на срок ввода в эксплуатацию) Объем финансирования в соответствии с ФП (млн. руб.) Год, по которому сформирован отчет Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Сводная бюджетная роспись на отчетную дату Значение характеристики не может изменяться участником закупки Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект - - Значение характеристики не может изменяться участником закупки - ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») - 1 Общие сведения 1.1 Наименование системы - Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование Заказчика и Подрядчика - Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры - - Значение характеристики не может изменяться участником закупки - 1.3 Основания для выполнения работ - 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; - - Значение характеристики не может изменяться участником закупки - 10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010; - 17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ - 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - - Значение характеристики не может изменяться участником закупки - 11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»; - 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации - 1.5 Сроки начала и окончания работ - Начало работ: с даты заключения Контракта. Окончание работ: не позднее 30.06.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего ТЗ (далее – Календарный план) - - Значение характеристики не может изменяться участником закупки - 1.6 Порядок оформления и предъявления результатов работ - Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5.1 настоящего ТЗ, в соответствии с Календарным планом и Контрактом - - Значение характеристики не может изменяться участником закупки - 1.7 Место выполнения Работ - Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет. Тестовый стенд для проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний предоставляет Заказчик. Доступ к тестовому стенду Заказчик предоставляет Подрядчику на основании письменного обращения. Требования к предоставляемым вычислительным мощностям должны соответствовать требованиям, указанным в пояснительной записке, представляемой на этапе № 1 работ - - Значение характеристики не может изменяться участником закупки - 2 Назначение и цели развития Системы 2.1 Назначение Системы - Основными задачами, решаемыми в настоящий момент системой АСУ ТК, являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов контроля безопасности и устойчивости транспортного комплекса, управления в чрезвычайных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими органами государственной власти, а также гражданами и организациями - - Значение характеристики не может изменяться участником закупки - АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными стратегическими целями развития АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и принятия мер по их устранению и ликвидации последствий - 2.2 Цели развития Системы - Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - Основными целями выполнения работ являются: – создание среды взаимодействия участников строительства на этапах реализации процесса строительства (реконструкции); – создание единого источника достоверной, непротиворечивой и верифицированной информации для принятия решений на всех управленческих уровнях; – повышение достоверности и прозрачности информации об инвестиционных проектах и программах; – повышение дисциплины формирования и предоставления плановых и отчетных форм; – обеспечение единого информационного пространства инструментам регистрации, хранения, согласования документов-обоснований; – обеспечение инструментов контроля полной стоимости, статей затрат по базовым, текущим ценам и ценам инвестиционного проекта, и физическим характеристикам; – обеспечение формирования графиков, контроля исполнения и сигнализация рисков неисполнения контрольных этапов; – повышение прозрачности процессов и оптимизация взаимодействия между различными участниками реализации инвестиционных проектов. Достижение указанных целей осуществляется для достижения стратегических целей развития АСУ ТК, указанных в пункте 2.1 ТЗ. Основные процессы, автоматизируемые в рамках выполнения Работ: – управление инвестиционными проектами строительства и реконструкции; – управление разработкой и согласование ПИР на всех стадиях реализации проекта; – управление задачами участников проектов строительства и реконструкции; – формирование и согласование исполнительной документации; – формирование и ведение календарно-сетевого планирования; – проведение процедуры строительного контроля; – формирование отчетности - 2.3 Состав выполняемых задач - Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей - 3 Сведения об объектах автоматизации 3.1 Описание объектов автоматизации - Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими органами государственной власти, гражданами и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. В соответствии с Аттестатом соответствия требованиям по защите информации АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - - Значение характеристики не может изменяться участником закупки - 3.2 Текущее состояние объекта автоматизации - Текущая архитектура АСУ ТК приведена на рисунке 1. Рисунок 1 – Архитектурная схема АСУ ТК АСУ ТК осуществляет идентификацию и авторизацию посредством ЕСИА. Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3, СМЭВ 4, а также с использованием технологий API и FTP с учетом требований Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России», утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД. АСУ ТК развернута на вычислительных мощностях Головного центра обработки данных ФБГУ «СИЦ Минтранса России». На этапе технического проектирования Подрядчик формирует требования к необходимым вычислительным мощностям для разворачивания ПО, создаваемого в рамках настоящего ТЗ. В текущей конфигурации Подсистема «Мониторинга комплексного плана» (П-МКП) обеспечивает выполнение следующих основных функций: – обеспечение оперативного взаимодействия участников реализации КПМИ в цифровой форме при подготовке, изменении и реализации планов-графиков ФП КПМИ; – визуализация содержащихся в П-МКП данных, представление их в удобном для анализа виде; – ранжирование объектов планов-графиков ФП КПМИ, в соответствии с Методикой ранжирования отдельных мероприятий, включаемых в ФП КПМИ на период до 2024 года ; – мониторинг исполнения планов-графиков ФП КПМИ, включая сбор, обработку, представление данных, необходимых для мониторинга и формирования отчетов на основе данных мониторинга планов-графиков в соответствии с Методическими указаниями по мониторингу и внесению изменений в Комплексный план модернизации и расширения магистральной инфраструктуры на период до 2024 года (транспортная часть) и ФП КПМИ - - Значение характеристики не может изменяться участником закупки - АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи - 1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП - 3.2.1. Состав используемого ПО - Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. - - Значение характеристики не может изменяться участником закупки - Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ - Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ) - 3.3 Объект автоматизации в рамках настоящего Технического задания - Предметом автоматизации является объединение в едином информационном пространстве данных по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, в отношении которых предусмотрена реализация мероприятий по строительству (реконструкции) в рамках национальных и федеральных проектов. Объекты автоматизации перечислены далее - - Значение характеристики не может изменяться участником закупки - 3.3.1. Физические объекты - Объекты транспортной инфраструктуры, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – автомобильные дороги федерального, регионального, межмуниципального и местного значения; – железнодорожные пути и станции, сопутствующая инфраструктура; – аэродромы и аэропортовые комплексы; – морские и речные порты, причалы, судоходные гидротехнические сооружения. Иные объекты, относящиеся к ведению Минтранса России, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – суда, в том числе аварийно-спасательный и вспомогательный флот; – пункты пропуска через государственную границу Российской Федерации - - Значение характеристики не может изменяться участником закупки - 3.3.2. Информационные объекты - Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) - - Значение характеристики не может изменяться участником закупки - 3.3.3. Процессы автоматизации - Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных - - Значение характеристики не может изменяться участником закупки - 3.3.4. Взаимодействие участников - Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах - - Значение характеристики не может изменяться участником закупки - 4 Требования к Работам - Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы - - Значение характеристики не может изменяться участником закупки - 4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре - 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 - - Значение характеристики не может изменяться участником закупки - 17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17 - Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком. - В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей - Уровень хранения данных: – распределенные базы данных; – предзаполненный набор справочников, содержащих нормативно-справочную информацию; – отдельно вынесенный базовый функционал, обеспечивающий сохранение и обработку данных. Уровень информационного взаимодействия: – выполнение автоматизированных операций, обеспечивающих подготовку (агрегирование данных) и передачу данных между контурами. Уровень файлового хранения: – распределенная файловая система, обеспечивающая хранение и обработку загруженных в систему файлов. Уровень работы микро- и макросервисов: – запускаемые в асинхронном режиме application instance, нацеленные на выполнение отдельных ресурсоемких задач и использующие минимальный набор внутренних зависимостей, необходимых для выполнения задачи. При проектировании и разработке всех составляющих компонентов следует использовать единую методологию и единые принципы взаимодействия, надежности и управления - 4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков - № Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4 - 4.1.2 Требования к режимам функционирования П-МКП по результатам Работ - П-МКП должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования должен быть штатный. В штатном режиме все подсистемы корректно и полностью должны выполнять свои функции. Перерывов в работе как П-МКП в целом, так и одного, либо нескольких компонентов, не предусмотрено. Режим регламентного (профилактического) обслуживания должен быть предназначен для проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе П-МКП с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию П-МКП и их периодичность должны быть определены Подрядчиком в процессе выполнения работ по созданию П-МКП. В режиме регламентного (профилактического) обслуживания П-МКП может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода П-МКП в данный режим, должен быть определен Подрядчиком - - Значение характеристики не может изменяться участником закупки - Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.3 Показатели назначения - В рамках выполнения работ по развитию Системы, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице 3. Таблица 3 – Определения показателей, связанных с количеством пользователей в подсистеме «Мониторинга комплексного плана» (П-МКП) № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечивать Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения - - Значение характеристики не может изменяться участником закупки - Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице 4. Таблица 4 – Значения показателей количества пользователей подсистемы «Мониторинга комплексного плана» (П-МКП) № Показатель Значение 1 Расчетное количество пользователей 1000 2 Расчетное среднее количество одновременно работающих пользователей 500 Развитие Системы должно быть направлено на достижение следующих описаний ключевых результатов (ОКР), в рамках ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» мероприятия 1 ВПЦТ Минтранса России на период 2026-2028: · «Реализован функционал цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры подсистемы «Мониторинга комплексного плана» АСУ ТК». · «Проведено импортозамещение подсистемы «Мониторинга комплексного плана» АСУ ТК» - 4.1.4 Требования к надежности функционирования и доступности для пользователей - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надежность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счет: – обеспечения требуемого уровня квалификации обслуживающего персонала; – регламентации и нормативного обеспечения выполнения работ обслуживающего персонала; – своевременной диагностики неисправностей. Расчетное значение коэффициента готовности АСУ ТК должно составлять не менее 0,95. Планы и процессы обеспечения непрерывности функционирования АСУ ТК должны быть увязаны с перечнем наиболее критических компонентов АСУ ТК, перечнем наиболее важных информационных ресурсов АСУ ТК - - Значение характеристики не может изменяться участником закупки - ПО АСУ ТК должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов АСУ ТК; – сохранение работоспособности ПО при некорректных действиях пользователя; – резервное копирование БД Системы. Средства АСУ ТК по итогам развития должны обеспечивать следующие характеристики надежности при определенном уровне доступности функций: – операционное время: 24x7; – время восстановления работоспособности Системы после отказа или проведения регламентных работы: не более 4 часов; – отказоустойчивость на уровне 99% при единовременном обращении к Системе не менее 10 пользовательских сессий. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи публичных сетей. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Система должна автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом или исполняемых программных кодов Системы либо ее компонент) - 4.1.5 Требования по диагностированию Системы - Компоненты АСУ ТК должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО. АСУ ТК должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы. Диагностирование должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего ПО Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного ПО серверов Системы; – сбои и нарушения функционирования прикладного ПО серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в ПО диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы - - Значение характеристики не может изменяться участником закупки - 4.1.6 Требования к транспортабельности - Не предъявляются - - Значение характеристики не может изменяться участником закупки - 4.1.7 Требования к эксплуатации и техническому обслуживанию - Обслуживание Системы должно производиться обслуживающим персоналом. Допускается использование специализированных служб или подразделений на объектах внедрения для обслуживания и ремонта оборудования. При эксплуатации Системы должны использоваться штатные методы защиты от механических, тепловых, электромагнитных и других воздействий, защиты данных, в том числе, от несанкционированного доступа к ним, применяемые у Заказчика. Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Системы. При возникновении неисправностей должно осуществляться оперативное обслуживание - - Значение характеристики не может изменяться участником закупки - 4.1.8 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды - Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - - Значение характеристики не может изменяться участником закупки - 4.1.9 Требования к информационной безопасности - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего : – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - - Значение характеристики не может изменяться участником закупки - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 17, 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 20, 20.14, 25(1) и 25(2) Требований, о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11.02.2013 № 17; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.10 Требования к безопасности исходного кода - Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО - - Значение характеристики не может изменяться участником закупки - Заказчик предоставляет результаты контрольных проверок, зафиксированных в артефактах сборочного процесса, Подрядчику для устранения в срок до даты завершения исполнения Контракта. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности и т.д., в случае, если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента - 4.1.11 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов - Требования к эксплуатации оборудования Заказчик обеспечивает самостоятельно или с помощью привлеченных сторонних организаций. Для нормальной эксплуатации разрабатываемого ПО должно быть обеспечено бесперебойное питание серверов. При эксплуатации должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации серверов температура и влажность воздуха. - - Значение характеристики не может изменяться участником закупки - 4.1.12 Требования по сохранности информации при авариях - При аварийных ситуациях в АСУ ТК должна обеспечиваться сохранность информации. Реализуемые технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т. п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - - Значение характеристики не может изменяться участником закупки - 4.1.13 Требования к патентной чистоте и патентоспособности - 4.1.13.6. В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке) или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия – Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО; – должны передаваться исходный код, дистрибутивы, эксплуатационная и техническая документация. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности, предоставления правообладателям доступа к ПО и т.п.), не предусмотренные Контрактом - - Значение характеристики не может изменяться участником закупки - 4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1.13.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке по соответствующему этапу исполнения контракта. Разработанное ПО поставляется вместе с исходными кодами. - 4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности - 4.1.13.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.13.4. Подрядчик должен подтвердить, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части и иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними - 4.1.13.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам - 4.1.13.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта - 4.1.14 Требования к численности персонала оператора Системы - Дополнительные требования к численности персонала оператора не предъявляются - - Значение характеристики не может изменяться участником закупки - 4.1.15 Требования к квалификации персонала Системы, порядку его подготовки и контроля знаний и навыков - Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере, к системным администраторам предъявляются следующие требования: – знание основных принципов построения СУБД; – наличие расширенных знаний в области поддержки пользователей; – знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации - - Значение характеристики не может изменяться участником закупки - 4.1.16 Требуемый режим работы персонала оператора Системы - Режим работы персонала должен соответствовать действующему законодательству Российской Федерации (РФ) и обеспечивать работоспособность Системы согласно требованиям, предъявленным настоящим ТЗ. Должна быть учтена возможность сменного режима работы персонала Системы. При этом должна учитываться возможность круглосуточного подключения к работам специалистов, обеспечивающих функционирование Системы (администраторов и специалистов по техническому обслуживанию), для решения проблем по обеспечению работоспособности информационных ресурсов Системы - - Значение характеристики не может изменяться участником закупки - 4.1.17 Требования к эргономике и технической эстетике - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя манипулятора типа «мышь», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов. Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских веб-интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АСУ ТК должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АСУ ТК. Визуальное представление элементов пользовательского интерфейса АСУ ТК и состав отображаемой информации подлежат согласованию Заказчиком в процессе выполнения работ по модернизации Системы - - Значение характеристики не может изменяться участником закупки - Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме, возможно, системных сообщений), должны быть на русском языке. Все экранные формы должны иметь текстовую справку, в которой должна быть описана инструкция по работе с данной экранной формой. На всех экранных формах при выполнении операций должна быть выведена индикация, которая информирует пользователя о статусе выполнения операции. Система должна обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введеенных значениях - 4.2 Требования к содержанию работ 4.2.1 Архитектурное решение - 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - 4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком - 4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур. - 4.2.2 Требования к масштабируемости и расчету мощностей - 4.2.2.1 Модульность и горизонтальное масштабирование Архитектура ПО должна быть модульной и поддерживать горизонтальное масштабирование (scale-out) контуров без изменения исходного кода приложения. Функциональный контур масштабируется путем создания копий и подключения к сервису передачи агрегированных данных в информационно-аналитический контур. При этом могут применяться стратегии административного, функционального или географического разделения пользователей по экземплярам контура, в том числе с помощью настройки конфигурации приложения каждого экземпляра. Критичные компоненты, такие как серверы приложений, веб-сервисы и обработчики очередей, должны быть спроектированы как независимые, stateless (бессостоятельные, не сохраняющие состояние на самом сервере) сервисы. Хранение состояний приложения возможно с использованием СУБД. Это позволит увеличивать производительность и отказоустойчивость за счет добавления новых экземпляров сервисов в пул под нагрузкой балансировщика - - Значение характеристики не может изменяться участником закупки - 4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ - 4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов - 4.2.3 Требования к функциональным блокам информационно-аналитического контура - 4.2.3.1 АРМ Сотрудника Функциональный блок должен обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников: – сводной информации, полученной из функционального контура; – информации, сформированной в иных системах (программных продуктах) и загруженной с помощью импорта файла формата xlsx установленной структуры. Информация, собираемая и показываемая в АРМ Сотрудника, должна иметь возможность быть представленной как в рамках конкретного объекта, так и в рамках группы объектов, заданной набором фильтров. В состав данной информации должны входить показатели исполнения объекта, финансовые показатели, фиксация прохождения контрольных точек реализации исполнения. Для показа информационной сводной панели необходимо разработать функциональный блок настраиваемых аналитических панелей - компонент графического представления данных для отображения набора настраиваемых виджетов с возможностью создания (настройки) панелей для анализа информации по различным бизнес-процессам. Для формирования и выгрузки аналитических данных в форме табличного отчета необходимо разработать функциональный блок отчетности. Данный компонент должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов и достижении ключевых событий. Для сбора информации, необходимой для формирования аналитических панелей и отчетов, требуется разработать функциональный блок загрузки данных. Компонент должен обеспечивать регулярную автоматическую загрузку данных из контура функционального уровня в сводном агрегированном виде, достаточном для показа на панелях и для формирования отчетов. Кроме того, в компоненте должна быть предусмотрена возможность ручной загрузки данных в подготовленном формате - - Значение характеристики не может изменяться участником закупки - 4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта) - Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер должен представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также требуется реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания; – переход в информационный паспорт объекта во вкладке таблицы. - Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». - Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов. Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Освоено» должен отображать освоение (принято) в млн. руб. с разделением по годам, с фильтрацией по признакам: – всего нарастающим итогом с начала реализации (до утв. паспорта ФП); – всего нарастающим итогом после утверждения паспорта ФП; – всего с начала отчетного года; – всего с начала отчетного месяца; – всего по контракту/контрактам. Виджет «Контрактация» должен отображать плановый объем финансирования по контракту/ контрактам в отношении к «Законтрактовано в млн. руб» с нарастающим итогом с начала отчетного года. Необходимо реализовать фильтрацию по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Контрактация по контрактам» должен отображать сводную информацию о видах и количестве контрактов, которые были заведены. Виджет «Обеспеченность машинами и механизмами» должен отображать наличие машин и механизмов по плановому и фактическому значению в разрезе объектов. Виджет «Динамика по трудовым ресурсам (чел.), машинам и механизмам (в ед.)» должен отображать привлечение трудовых ресурсов по плану-факту с возможностью фильтрации по периоду. Виджет «Строительная готовность объекта» должен отображать готовность объекта в процентах. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Паспорт объекта должен содержать следующие вкладки: – «Паспорт» (информация и параметры объекта, участники строительства, сведения о затратах с фильтрацией по бюджетам, проблемные вопросы); – «Показатели» с возможностью редактирования; – «Финансирование» (сведения о выделенных и доведенных д\с в разбивке по бюджетам); – «Контракты» (сведения о заключенных контрактах по объекту с возможностью редактирования); – «Строительный контроль» (количество выявленных недостатков по типам; – «Подробные сведения о выявленных недостатках» с возможностью редактирования; – «Проблемные вопросы» (сведения о проблемных вопросах в разбивке по типам); – «Задачи» (доступ к функциональному блоку по работе с задачами с возможностью создания новых задач); – «Фотогалерея» (изображения с площадки строительства объекта). Необходимо реализовать виджеты, отображающие аналитическую информацию о количестве контрольных точек (далее - КТ), отражающих ход реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, относящихся к ведению Минтранса России. Все виджеты данной группы должны иметь следующие фильтры по: – национальным и федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – статусу достижения; – видам работ (проектирование, получения заключения государственной экспертизы проектной документации, строительно-монтажные работы, ввод в эксплуатацию и др.) - Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов должна раскрываться таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ. Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и их срок . Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о соблюдении ранее установленного срока, выполненных ранее срока, выполненных в срок, не выполненных в срок (срок истек), не выполненных (срок не наступил). Виджет «Контрольные точки, риски» должен отображать общее количество объектов, количество завершенных объектов, количество объектов с высокой степенью риска, со средней и умеренной/ отсутствующей. При нажатии на количество объектов должна открываться таблица с объектами и контрольными точками, отображающими текущую КТ, план и факт по каждой контрольной точке с подсвечиванием отставания соответствующим цветом. Зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев; Необходимо реализовать виджет, который отображает аналитическую информацию о текущих и прогнозных рисках и их влиянии на показатели национальных и федеральных проектов с возможностью выбора параметра (мощности), влияние на который оказывают объекты, и добавления фильтров по: – федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств - 4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.3.4 Функциональный блок загрузки данных Функциональный блок предназначен для обеспечения информационного обмена со смежным контуром и должен обеспечивать получение (загрузку) актуальных данных по проектам, объектам, их финансированию и контрольным точкам исполнения. Данные должны сохранятся в функциональном блоке в агрегированном (сводном) виде и использоваться в качестве источника информация для построения виджетов аналитической панели, а также отчетов. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных; – преобразования данных; – сохранения данных; – хранения истории запусков. Должны быть реализованы следующие стратегии загрузки: – ручная загрузка данных, предоставленных в файлах; – автоматическая загрузка данных из смежного контура. Автоматический режим подразумевает под собой фоновую регулярную загрузку сводной информации, собранной на основе актуальных данных, вводимых в функциональные блоки Ручной режим загрузки должен обеспечивать возможность загрузки данных по шаблону. Файл для загрузки должен быть в формате *xlsx. Данные могут предоставляться как в полном объеме шаблона, так и в частичном. Функция преобразования данных из файла формата xlsx должна использовать следующие стратегии: – валидация данных на соответствие шаблону; – применение функций преобразования к отдельным полям источника данных, такие как приведение типов, преобразование формата даты; – агрегация данных по выбираемым категориям; – применение функций преобразования для получения вычисляемых значений; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования - Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция хранения истории запусков должна фиксировать следующую информацию: – дата и время загрузки; – название источника; – статус загрузки; – сообщение об ошибках (при наличии). При помощи шаблона предполагается загрузка следующей сводной информации по объектам строительства: – наименование объекта строительства, федерального проекта, инвестиционного проекта, указание местоположения и пр. основные характеристики; – общая информация об объекте, включающая в себя плановые и фактические показатели с детализацией по годам за 5 лет; – плановые и фактические показатели хода реализации, описывающие сроки достижения контрольных точек этапов проектирования и строительства; – плановые финансовые показатели с детализацией по годам и источникам финансирования, включающие в себя объем финансирования и план освоения; – плановые и фактические показатели по контрактации; – плановые и фактические показатели по обеспеченности машинами и механизмами; – плановые и фактические показатели по привлечению трудовых ресурсов; – информация о строительной готовности; – информация об уровне риска реализации и необходимым мерам. Данные, переданные в функциональный блок посредством ручной загрузки отчета, должны сохраняться как в сводном виде, подходящем для показа в аналитических панелях, так и фиксироваться в виде пакета (отчета) с сохранением времени загрузки и автора - В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4 Функциональные требования к блокам функционального контура - Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; - - Значение характеристики не может изменяться участником закупки - – возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Необходимо разработать следующий функционал: – возможность формирования графика производства работ по проекту, в том числе на основании загруженных смет; – возможность формирования сущностей типа «запись ГПР», «Суммарная запись ГПР», «веха»; – возможность ручного добавления, удаления и перемещения по структуре работ в графике; – формирование зависимостей между работами в ГПР с установкой временных задержек; – возможность редактирования внесенного этапа работ; – назначение ответственных и исполнителей на конкретные работы графика, возможность делегирования работ; – возможность полного или частичного делегирования графика в другие версии; – возможность полуавтоматического переноса фактических показателей из делегированной версии в основную; – поддержка версионности и стадийности графиков; – возможность формирования директивной версии графика (базового плана) и заполнения новой версии ГПР на ее основании; – возможность копирования версии ГПР; – возможность сравнения связанных версий графиков между собой; – автоматический расчет критического пути с возможностью отображения только тех работ, которые принадлежат критическому пути; – автоматический расчет прогнозных сроков выполнения работ на основании динамики фактического выполнения работ; – настройка визуального отображения диаграммы Ганта; – возможность удалить этап работ из графика; - 4.2.4.4.3.5. Виджеты по тематике «Отображение аналитической информации по объектам и направлению на панели руководителя проекта» Группа виджетов должна отображать текущие показатели по объекту направления. У группы виджетов должен быть предусмотрен фильтр по направлениям (воздушный транспорт, железнодорожный транспорт, морской транспорт, речной транспорт): – стоимость контракта; – дефицит (отображает разницу между доведенными лимитами и стоимостью объекта по ССР); – непогашенный аванс (разница между суммой выданного аванса и погашенного по КС-3); – банковская гарантия с указанием даты завершения (из контрактов); – строительная готовность объекта, отображаемая в процентах, и динамика за неделю по задействованным трудовым ресурсам (чел.) и машинах и механизмах (в ед.); – характеристика объекта; – эффекты, которые оказывает объект строительства; – необходимые решения; – ход исполнения; – фотография объекта. Также по объекту из направления должна отображаться таблица с диаграммой Ганта со столбцами: – номер по порядку; – наименование объекта; – длительность (дней); – начало (дата); – окончание (дата); – диаграмма с разделением по кварталам. Виджет «Отчет по объекту» должен содержать три окна: – в первом окне – «Эффект от реализации»; – во втором окне – «Информация об объекте/Проблемные моменты» со следующим перечислением: 1) поле «Заключен ГК» (необходимо указать юридическое лицо, с которым заключен контракт), далее необходимо показать вид работ из контракта, дату заключения договора и номер контракта; 2) отображение информации о текущей контрольной точке объекта и плановой дате; 3) информация по контракту (дорожная карта); 4) дата ввода объекта в эксплуатацию с комментарием); 5) поле «Виды работ»; 6) изменения количества рабочих/техники с разбивкой по месяцам с даты начала СМР; – в третьем окне – «Предложения по решению проблем» - 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. - Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных из файлов формата xml; – преобразования данных; – сохранения данных; – фиксация выполненных действий по созданию/изменению в истории событий. Функция преобразования данных из файла формата xml должна использовать следующие стратегии: – валидация файла на соответствие xsd-схемам, утвержденным Минстроем России и опубликованным на официальном сайте как актуальные; – валидация данных файла на соответствие форматам ожидаемых данных и данным, уже имеющимся в П-МКП, в т.ч. проверка наличия и доступности пользователю объекта строительства, юридических лиц, указанных в документе. Полный набор критериев валидации должен быть разработан на этапе № 1 Календарного плана; – применение функций преобразования к отдельным полям источника данных, таким как приведение типов, преобразование формата даты; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования. Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция сохранения истории событий должна фиксировать в т.ч. следующую информацию: – дату и время события; – название события; – автора события; – сохраняемые или изменяемые данные - Данные, полученные на основании загруженного файла, должны сохраняться в качестве документов или записей, соответствующих данному документу, с фиксацией всей информации, содержащейся в файле (в т.ч. объект строительства, юридические и физические лица, информация об объемах, суммах и пр). Файл формата xml, на основании которого создан документ или запись, должен быть прикреплен к карточке этой записи и доступен для скачивания. Документы и записи, созданные посредством загрузки данных из файлов xml, должны быть доступны загрузившему их пользователю в соответствующей вкладке АРМ Подрядчика, а также сотрудникам Заказчика, имеющим доступ к объекту строительства. Функциональный блок должен поддерживать возможность загрузки файлов с измененными данными по документу (новые версии документа) с возможностью связать созданный документ с его предыдущими версиями или обновить (заменить) данные в уже существующем документе без создания новой версии. Во втором случае файл, содержащий данные об изменениях, должен быть прикреплен в качестве новой версии исходного файла. В функциональном блоке должна быть возможность разграничения прав на загрузку отдельных видов документов, определяемая настройкой прав пользователей и ролевой моделью. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов - В рамках функционального блока требуется разработать следующий набор вкладок: – список доступных Подрядчику объектов с возможностью фильтрации по общей информации об объекте (тип, вид статус, адрес объекта, участники реализации и др.) и просмотра краткой информации по каждому из них. Общий перечень данных в карточке не должен превышать описанный в разделе функциональный блок «Информация»; – вкладки с реестрами загруженных документов с возможностью группировки по типам и объектам, с возможностью перехода к карточке документа; – карточки отдельных документов, содержащие в себе основную информацию о документе и его участниках, версию документа, прикрепленный файл в формате xml, на основании которого документ был создан, список замечаний, выданных по документу, возможность выполнения действий по согласованию и подписанию с использованием функционального блока для ведения электронного документооборота (СЭД); – вкладка загрузки данных из файлов формата XML по схемам, определенным Минстроем России для передачи документов в электронном виде и опубликованным на официальном сайте; – список пользователей, являющихся представителями Подрядчика и имеющих доступ к АРМ Подрядчика и конкретным объектам в нем, с возможностью управления доступом, подключением новых пользователей и блокировкой ранее подключенных. Необходимо предусмотреть возможность для администратора от Подрядчика управлять доступом отдельных пользователей к конкретным объектам строительства; – список аккаунтов для взаимодействия с внешней системой электронного документооборота, в случае использования Удостоверяющего центра для подписания документов с использованием КЭП (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). - Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); - 4.2.4.4.3. Требования к созданию виджетов Необходимо разработать следующий функционал: – реализовать возможность точечной настройки аналитических виджетов по дате формирования данных (при необходимости); – выполнить возможность непосредственного перехода от информации на виджете дашборда к источникам данных; – реализовать возможность пользовательской настройки отображения и группировки виджетов - 4.2.4.2 АРМ Заказчика Функциональный блок АРМ Заказчика должен включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны Заказчика доступом к АРМ Подрядчика для сотрудников Подрядчиков. Функционал должен обеспечивать следующие возможности: – просмотр списка новых объектов строительства; – возможность перехода к карточке объекта, возможность добавления новых объектов; – просмотр списка юридических лиц, выступающих Подрядчиками на проектах, возможность просмотра информации о них, добавления новых, редактирования и удаления созданных ранее; – возможность создания АРМ Подрядчика для юридических лиц, выполняющих работы на объекте; – просмотр списка пользователей, являющихся представителями подрядчика, управление их доступом к АРМ Подрядчика, возможность добавления новых и блокировки неактуальных (уволенных, прекративших свою деятельность по проекту). Функциональный блок должен разрабатываться в интерфейсах, аналогичных АРМ Подрядчика. Информация представляется в виде вкладок, осуществляющих: – работу с объектами строительства; – работу и управление Подрядчиками; – настройку АРМ Подрядчика; – управление пользователями АРМ Подрядчика; – просмотр и работу с предоставленными документами через механизм загрузки в формате XML. Объем данных, выводимых в каждой вкладке, регулируется правами доступа пользователя-администратора Заказчика к объектам и юридическим лицам. Доступ к АРМ Заказчика в целом и к конкретным вкладкам в нем, должен управляться настройкой прав пользователя. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией - 4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); - 4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.4.2. Требования к отображению объекта на интерактивной схеме Функционал должен включать отображение объектов на интерактивной схеме РФ, расположенной на аналитической панели – дашборд. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта). Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также необходимо реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры); – годам; – Заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - – Виджет «Текущая аналитика СМР по ГПР» должен отображать данные по выполненным работам и освоенным средствам. Учитываются только данные из актуальных ГПР стадии СМР; – Виджет «Мониторинг исполнения ГПР, СМР» должен отображать сводную информацию о сроках исполнения плановых графиков ГПР по работам СМР (в сравнении с фактическими датами начала/окончания работ в ГПР); – Виджет «Мониторинг строительного контроля» должен отображать информацию о недостатках, выявленных в ходе проверок инспектором строительного контроля по всем объектам базы; – Виджет «Недостатки» должен отображать информацию о количестве недостатков, выявленных в ходе проверок строительного контроля в разбивке по их текущему статусу; – Виджет «Качество исполнительной документации» должен отображать количество документов, находящихся на согласовании, количество подписанных ЭП и количество выданных замечаний к документации; – Виджет «Стадии реализации (текущие)» должен отображать количество объектов по текущим стадиям реализации строительства, указанным в функциональном блоке «График производства работ» - 4.2.4.4.3.3. Виджеты по тематике «Управление проектами» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Статус объектов проектирования и строительства» должен отображать статус объектов; – Виджет «Актуальные вопросы (количество, статусы)» должен отображать количество и статусы по актуальным вопросам по объектам; – Виджет «Технико-экономические показатели реализуемых объектов» должен отображать сводную информацию об основных технико-экономических показателях объектов; – Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов раскрывается таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ; – Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и срок которых не наступил. Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о выполненных ранее срока, выполненных в срок и «Не выполнено. срок истек», «Не выполнено. Срок не наступил» - 4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам - 4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных - К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - – возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки) - 4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации) - Также на данном дашборде необходимо отобразить: – столбчатую горизонтальную диаграмму «Бюджетные обязательства/ Касса по годам», в которой должны отображаться данные показатели в разрезе по годам. Ниже должна быть отображена таблица с данной информацией; – столбчатую горизонтальную диаграмму «Авансы», отображающую информацию на текущий год: 1) всего аванса по контракту; 2) раскассировано аванса (сумма, которую Подрядчик может потратить со счета авансовых средств. Данные поступают от Подрядчика в виде сведений об операциях для утверждения. Источник данных – система «Электронный бюджет» (можно выгрузить в виде отчета в формате *xls); 3) выплачено аванса (фактическая сумма, перечисленная Подрядчику по выставленным им счетам. Данные поступают из бухгалтерии и также могут быть получены из «Электронного бюджета»); 4) остаток к выплате (показатель рассчитывается как разница между стоимостью контракта, выплаченного аванса и оплаты по КС-2 (актам выполненных работ); 5) зачтено аванса (часть суммы аванса, которая закрывается (засчитывается) при выполнении работ и подписании актов по КС-2 (акты выполненных работ). Таким образом, сумма к оплате по новым актам уменьшается на размер зачтенного аванса); 6) неотработанный аванс (сумма перечисленного аванса, которая еще не закрыта (не зачтена) актами выполненных работ (КС-2), то есть это разница между выплаченным авансом и суммой, которая уже была зачтена); – кольцевую диаграмму «Работы», с информацией по: 1) выполненным работам; 2) остатку к выполнению - 4.2.4.4.3.7. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по нескольким объектам из направления» Данный дашборд должен отображать таблицу «светофор» со списком всех объектов по направлениям и со следующими столбцами: – номер по порядку; – наименование объекта; – подрядчик (если договор расторгнут, то необходимо отобразить статус и дату, также если договор планируется расторгнуть или он в процессе расторжения); – стоимость объекта (млрд); – дата начала; – дата завершения; – готовность. Объекты должны быть распределены в таблице и окрашены в соответствующие цвета в зависимости от риска реализации объекта. При наличии риска реализации объекта строка с наименованием объекта должна окраситься в красный, при наличии умеренного риска - в желтый, при отсутствии риска - в зеленый). Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9.2. Требования формированию плана освоения. Раздел функционального блока «ГПР» - вкладка «План освоения» Необходимо иметь возможность учитывать все виды ресурсов: материалы, машины и механизмы, рабочую силу, а также планировать их потребление. Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» представлены в таблице 7. Таблица 7 – Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» № п/п Функциональность вкладок 1 Должен формироваться план освоения в объемах и деньгах на основании графика работ с возможностью детализации по настраиваемым периодам распределения, настраиваемым типом расчета. В рамках плана освоения должна отображаться информация по плановым, фактическим показателям, показателям по директивному плану и закрывающим документам, а также показатели по отклонениям (план-факт, план-закрыто, факт-закрыто). 2 Должен отображаться ресурс типа -материалы. 3 Должен отображаться ресурс типа -машины и механизмы. 4 Должен отображаться ресурс типа -рабочая сила и кадры. 5 Должен позволять формировать накопительную ведомость - Также необходимо настроить систему уведомлений на почту ___@___ в системе. В уведомлении указываются сведения: 1) об объекте капитального строительства с указанием адреса (местоположения) объекта и времени проведения контрольных мероприятий; 2) о предъявляемых к освидетельствованию видов (этапов) работ, конструкций с указанием осей, пикетов, рядов, отметок или иных привязок мест расположения объекта освидетельствования и об участниках строительства, привлекаемых для выполнения указанных работ; – формирование аналитической информации по недостаткам; – отображение типовых нарушений со ссылкой на нормативные правовые акты; – замещение инспектора строительного контроля; – добавление недостатков, которые устранены в ходе проверки; – привязка недостатков к элементам BIM моделей; – привязка проверок к ПД/РД/ИД; – привязка недостатков к элементам графика производства работ; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: - – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); - – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); - – строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/) - 4.2.4.14 Функциональный блок ведения договоров «Управление проектом» Необходимо разработать следующий функционал: – формирование категорий контрактов; – формирование контрактов с указанием статусов, основных показателей и условий, предусмотренных контрактом (обязательства, авансы, дополнительные соглашения, гарантийные удержания и др.); – формирование и учет платежей по контрактам с привязкой к типу, план/факт, не законтрактовано (год) и типу бюджета; – формирование дополнительных соглашений к контракту с автоматическим изменением суммы, плановой даты начало/окончания контракта; – аналитика контрактов по текущим статусам, видам и типам выполняемых работ на объекте. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.8 Функциональный блок «Информация» Данный функциональный блок содержит требования к функциям ведения карточек проектов и программ. В рамках выполнения Работ необходимо организовать ввод, обмен и хранение, и актуализацию данных по проектам и программам. Карточка объекта/программы должна содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и Подрядчиков по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков). Виды информации: – общая информация об объекте строительства (тип, вид статус, адрес объекта, участники реализации и др.); – данные по освоению денежных средств (кассовое исполнение, оплачено по контрактам, риск неосвоения лимитов); – отображение всех показателей объекта (технико-экономические показатели, статус реализации, градостроительная проработка и др.); – информация по финансированию объекта (выделение и доведение денежных средств); – информация по контрактам объекта; – информация по вопросам, возникающим в ходе реализации; – данные по выполнению задач по объекту; – фотогалерея; – видеонаблюдение в режиме реального времени. При открытии карточки объекта должен открываться функциональный блок «Информация», в котором указывается сводная информация по объекту, разделенная по вкладкам согласно таблице 5 - Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом - Необходимо разработать следующий функционал: – автоматическое формирование плана освоения на основании сформированного графика с отображением данных, введенных в ГПР в табличной форме по различным разрезам (стоимости и объемы работ) с возможностью выбора детализации отображения по временным периодам (день / неделя / месяц / квартал / год) и типу отображения (раздельно или накопительно) и возможностью отображения различных показателей – работы / материалы / машины и механизмы / рабочая сила и кадры; – автоматическое создание плана освоения денежных средств и физических объемов выполняемых работ в разрезах рабочей силы (чел-час), ресурсов машин и механизмов (маш-час), материалов (ед. изм.); – возможность настройки отображения показателей, а также настройки диапазона дат; – формирование графика фактического освоения денежных средств и объемов по кварталам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.10 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Необходимо разработать следующий функционал: – реализация многоуровневого списка категорий документов ПИР с предустановленными значениями категорий и возможностью добавлять категории самим пользователем в случае необходимости; – наличие предустановленных шаблонов печатных форм документов «Задание на проектирование» и «Задание на инженерные изыскания», возможность выгрузить из документа в виде текстового документа; – реализация процедур согласования и подписания с помощью ЭП документов «Задание на проектирование» и «Задание на инженерные изыскания», «Программа инженерных изысканий» с отображением статуса согласования и подписания соответствующего документа; – возможность сформировать шаблон согласования и указание информации требуется ли наличие предыдущего согласования для этого уровня для выполнения процедуры согласования; – ввод, сортировка и хранение ИРД, проектной и рабочей документации в виде вложенных файлов документации ПИР; – согласование проектной документации с отображением статуса; – формирование и ведение реестров ИРД, проектной и рабочей документации; – возможность формирования документов с сохранением версий для отслеживания изменений проектной и рабочей документации; – реализация механизма работы пользователей с замечаниями к каждому отдельному документу ПИР, ДПТ; – процедура устранения замечаний исполнителем путем возможности внесения в карточку документа в разделе работы с замечаниями ответа о результатах работы над замечанием, включая прикрепления откорректированного документа (если требуется); - 4.2.4.16 Функциональный блок для ведения электронного документооборота Необходимо разработать инструмент для согласования документов, связанных с реализацией проектов. Требования к разрабатываемому функционалу функционального блока «СЭД»: – работа в СЭД с такими типами документов как: письма, контракты, закупочная документация, проектная/рабочая/исполнительная документация, соглашения, отчеты, первичные документы, приказы, протоколы, распоряжения, положения, служебные/докладные/пояснительные записки, аналитические справки, доверенности. Справочник типов документов должен быть открытый и при необходимости дополняемый; – обеспечение действий Пользователя в СЭД с документами внутреннего и внешнего, документооборота: делегирование, согласование, перенаправление, многостороннее согласование, многостороннее подписание. Реализовать возможность процедуры формирования маршрутов для согласования/подписания документов; – отображение в экранной форме Пользователя в СЭД таких параметров для каждого обрабатываемого документа, как: отправитель и получатель документа, заголовок документа, дата документа, автор документа, тип и статус обрабатываемого документа, крайний срок выполнения связанной с документом задачи. Реализовать возможность фильтрации по указанным параметрам для перечня обрабатываемых Пользователем документов; – формирование документов. Реализовать возможность устанавливать взаимосвязи создаваемых документов с уже существующими в СЭД; возможность формировать приложения к письмам для различных типов файлов, размещенных в т.ч. на ПК Пользователя; поиск по наименованию/ заголовку документа в СЭД по произвольному вводу символов для существующих в СЭД документов; содержать «Тэги» для быстрого поиска созданного письма в системе; возможность указывать метки «прочитано», «не прочитано» для входящей документации; возможность настройки Пользователем на экранной форме СЭД требуемых для отображения параметров; - – наличие истории документооборота, сохраняющего записи о всех событиях и их авторах в отношении каждого документа; – интеграция СЭД с вкладкой Планировщик задач, разделом «внутрисистемная почта» и разделом «уведомления». Организация списка документов: – создание раздела «Документы» в АРМ Подрядчика в соответствии с персональными возможностями доступа пользователя к документам; – ведение списка документов с разбивкой по процессам (этапам) и статусам документа: – карточка документа – этап для формирования карточки документа; – согласование – этап для согласования карточки документа с выделением следующих статусов: 1) на согласовании (получено согласование не от всех подписантов); 2) отменено инициатором (маршрут согласования снят инициатором); 3) согласовано (всеми подписантами); 4) отказано (получен отказ хотя бы от одного подписанта); – хранение документов с завершенным или отклоненным согласованием, организованно списком записей справочника, с предоставлением в табличном или ином виде. Должна быть реализована возможность поиска по атрибутам среди документов, доступных к просмотру: – наименование документа; – тип документа; – инициатор; – по связям с сущностями. Должна быть реализована возможность фильтрации документов по атрибутам, по этапам и статусам, по признаку «Я исполнитель», «Я инициатор», «Требует действий» - – формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы; - – процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта - Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий; - – просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»: - 4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи - – доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования); - Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов - 4.2.4.13 Функциональный блок ведения строительного контроля Необходимо разработать следующий функционал: – отражение результатов проведения инспекционной деятельности (проверки); – автоматическая генерация инспекционных документов (акт проверки и предписания) на основании зафиксированных недостатков; – работа с материалами фото и видеофиксация недостатков с возможностью сформировать отчеты о проведенных проверках и количестве выявленных недостатков; – формирование актов об устранении недостатков; – подписание актов проверки, актов инспекционного контроля, предписаний об устранении недостатков/о приостановке работ, отчета по устранению нарушений (с возможностью приложения документации, отправки отчета на почту), а также актов устранения недостатков; – формирование отчета по установленной форме; – разработка программы проведения инспекционного контроля по форме; – отображение статусов карточек документов и недостатков; – автоматическое направление участникам Проекта уведомлений о выявленных недостатках; – вызов инспектора строительного контроля на Объект (Уведомление о необходимости проведения СК на объекте оформляется на официальном бланке организации Генподрядчика. - – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - № п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии - 6 Должна содержать таблицу с информацией из графика производства работ о планировании и расходовании средств и ресурсов в рамках процесса строительства. В плане должно отображаться распределение стоимостей по периодам в разрезе стоимостей или объемов работ. 7 Должна иметь возможность формирования суточного графика работ в диапазоне дат с возможностью подневного ввода фактически выполненного объема. 8 Должна быть возможность сравнения версий, имеющих связи между собой - 4.2.5 Общие требования к функционированию - 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ - - Значение характеристики не может изменяться участником закупки - 4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02 - 4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы - 4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.5.3 Требования к обмену сообщениями В рамках выполнения Работ реализуется встроенный мессенджер, позволяющий обмениваться сообщениями между пользователями АРМ. Требования к разрабатываемому функционалу: – создание персональных чатов из списка пользователей из раздела мессенджера; – создание групповых чатов из раздела мессенджера; – возможность отправки текстовых сообщений и файлов; – поиск по списку чатов; – возможность удаления созданного чата; – корректировка перечня участников группового чата; – индикация групповых чатов в списке - 4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования - 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления - - Значение характеристики не может изменяться участником закупки - 4.3.5 Требования по применению систем управления хранилищами и базами данных Для хранения данных должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – наличие сертификата соответствия ФСТЭК России требованиям по защите информации, предъявляемым к системам управления базами данных не ниже 5 класса защиты; – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов - 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологической в инфраструктуре Заказчика. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика. 2) Допускается использование только кластеризованных баз данных. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре Заказчика. 3) Решение должно быть отказоустойчивым. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов. 4) Любые соединения, устанавливаемые решением, должны быть защищенными*. Примечания: 1 Защищенные соединения, выходящие за пределы контролируемой зоны, должны быть защищены с помощью программных и/или программно-аппаратных шифровальных (криптографических) средств, сертифицированных ФСБ России (далее – СКЗИ). 2 Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД; 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. Использование учетных записей с административными полномочиями не допускается - 4.3.2 Требования к организации хранилища данных Для хранения информации должна использоваться СУБД с возможностями распределенного хранения данных по кластерным узлам. СУБД предоставляется Заказчиком после завершения этапа № 1 Календарного плана. Структура БД должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в БД Системы. При проектировании структуры БД для хранения данных необходимо провести анализ реализованной структуры БД для П-МКП в целях использования в создаваемых АРМ. В результате анализа Подрядчик обязан представить Заказчику в Пояснительной записке описание структуры БД для функционирования АРМ с указанием переиспользуемых и вновь создаваемых таблиц БД. Информация должна размещаться в БД по возможности в нормализованной форме. Допускается использование дополнительных ненормализованных структур данных для повышения производительности. Допускается размещение отдельных параметров конфигурации во внешних конфигурационных файлах. Допускается размещение данных в нереляционных СУБД в случаях, предусматривающих очевидную выгоду в производительности, оптимизации требуемого места для хранения данных или необходимых вычислительных ресурсах по согласованию с Заказчиком. Полный перечень используемых программных решений должен быть определен Подрядчиком и согласован Заказчиком на этапе № 1 Календарного плана - 4.3.4 Требования к информационному обмену между компонентами Системы Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет - 5 Состав и содержание работ по развитию АСУ ТК - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) - - Значение характеристики не может изменяться участником закупки - 5.1 Состав работ и график их выполнения (календарный план) - 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 - - Значение характеристики не может изменяться участником закупки - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Сроки, установленные Календарным планом для каждого подпункта в рамках этапов, согласно таблице 11, включают подготовку, согласование, утверждение (для тех документов, в отношении которых требуется согласование или утверждение) отчетных, технических, рабочих документов с Заказчиком. Досрочная сдача результатов допускается по согласованию с Заказчиком. Сокращение периода (длительности) проведения опытной эксплуатации недопустимо. График выполнения работ по развитию АСУ ТК приведен в таблице 11. Таблица 11 – График выполнения работ по развитию АСУ ТК - № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа Ожидаемые результаты работ 1 Техническое проектирование. 1.1. Разработка частного технического задания Начало: с даты заключения контракта Окончание: не позднее 19.01.2026 Сопроводительным письмом предоставлены Заказчику: Частное техническое задание. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 1.2. Разработка технического проекта Начало: 19.01.2026 Окончание: не позднее 26.01.2026 Сопроводительным письмом предоставлены Заказчику: Технический проект в составе: - Описание архитектуры системы; - Пояснительная записка, включая описание автоматизируемых функций; - Описание программного обеспечения; - Описание информационного обеспечения; - Ведомость технического проекта; - Ведомость машинных носителей информации; - Руководство по безопасной разработке программного обеспечения. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу) - 2 Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Сопроводительным письмом предоставлены Заказчику: Исходные коды разработанного (передаваемого) программного обеспечения; Дистрибутивы разработанного (передаваемого) программного обеспечение; Инструкция по сборке; Паспорт П-МКП; Описание П-МКП; Руководство администратора; Руководства пользователей на каждый АРМ, включая рекомендуемые характеристики к ПК для АРМ; Документы по испытаниям в составе: - Программа и методика предварительных испытаний; - Протокол предварительных испытаний; - Программа и методика опытной эксплуатации; - Акт ввода в опытную эксплуатацию; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 - 3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026 - 6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации - Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ - - Значение характеристики не может изменяться участником закупки - 6.2 Виды, состав, объем и методы испытаний и его составных частей - В случае выявления ошибок в ПО П-МКП при проведении предварительных испытаний, Подрядчик должен их устранить до начала момента проведения опытной эксплуатации. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки). Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены Подрядчиком в документе «Программа и методика опытной эксплуатации». Программа и методика опытной эксплуатации должна быть утверждена Заказчиком до проведения опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» (с приложением журнала опытной эксплуатации) и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации, подтверждающий готовность П-МКП АСУ ТК и ее допуск к приемочным испытаниям - - Значение характеристики не может изменяться участником закупки - Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный - Результаты проведения предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от ТЗ оформляются как недостатки работ. Прочие недостатки могут документироваться как рекомендации. Наличие рекомендаций не влияет на процесс передачи П-МКП АСУ ТК в эксплуатацию. В случае значительного отклонения П-МКП АСУ ТК от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены или расширены Заказчиком. По результатам выполнения этапа № 3 должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии и сроки проведения испытаний. Испытания проводятся на площадке, указанной в программе и методике соответствующих испытаний, опытной эксплуатации. В состав комиссии включаются ответственные лица Заказчика и Подрядчика, а также, при необходимости, специалисты иных внешних организаций (например, экспертных), привлекаемые Заказчиком. Подрядчик обязан уведомить Заказчика о готовности к проведению испытаний официальным сопроводительным письмом и предоставить Заказчику программу и методику испытаний (далее – ПМИ). Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком и Подрядчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытаний и Акт о приемке в опытную эксплуатацию, подтверждающий готовность П-МКП АСУ ТК к следующему виду испытаний – опытной эксплуатации - Состав мероприятий, включенных в пилотную зону, может быть изменен по согласованию с заказчиком. В случае выявления ошибок в ПО П-МКП при проведении опытной эксплуатации, Подрядчик должен их устранить до начала приемочных испытаний. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки) Методы приемочных испытаний и порядок их проведения должны быть определены в документе «Программа и методика приемочных испытаний», который должен быть подготовлен Подрядчиком и утвержден Заказчиком до начала приемочных испытаний. По результатам проведения приемочных испытаний оформляются Протокол приемочных испытаний и Акт готовности П-МКП к эксплуатации. В Протоколе приемочных испытаний должны быть указаны перечень проверяемых сервисов, функций, возможностей, дата и время проведения приемочных испытаний, состав приемочной комиссии, рекомендации (при наличии) к решению, а также выводы о готовности П-МКП АСУ ТК к вводу в эксплуатацию. Ввод П-МКП АСУ ТК в эксплуатацию осуществляется после выполнения работ по ИБ, подписанием соответствующего акта - 6.3 Порядок контроля и приемки выполненных работ - Сдача-приемка выполненных работ осуществляется в соответствии с условиями Контракта. Сдача-приемка работ осуществляется по завершении каждого этапа в порядке, установленном в Контракте - - Значение характеристики не может изменяться участником закупки - 6.3.1 Условия о порядке предоставления (передачи) результатов выполнения работ Заказчику - Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ, а также в соответствии с инструкциями, приведенными в рабочей документации на П-МКП. Документация на П-МКП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - - Значение характеристики не может изменяться участником закупки - Передача исходных кодов, разработанных и/или передаваемых в ходе выполнения работ программ для электронных вычислительных машин (далее - программа для ЭВМ) и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных и/или передаваемых в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает заказчику исходные коды, дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения. - 6.4 Сведения о гарантийном обслуживании - Гарантийный срок: один год с даты подписания Заказчиком документа о приемке Этапа № 3. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, включая замечания и комментарии от федеральных органов исполнительной власти в области обеспечения безопасности, федерального органа исполнительной власти, уполномоченного в области противодействия техническим разведкам и технической защиты информации, Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерства транспорта Российской Федерации и Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций, выявленных после приемки выполненных Работ, в том числе в документации, разработанной по результатам выполненных Работ, касающиеся соответствия требованиям нормативных правовых актов, действующих на момент завершения этапа № 2. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, установленные Заказчиком в Акте с перечнем выявленных недостатков. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Гарантийным случаем признается полное или частичное отсутствие функционирования П-МКП и ее компонентов в результате выполнения работ по настоящему Техническому заданию. Подрядчик должен обеспечить гарантию работоспособности П-МКП, включая гарантийную поддержку - - Значение характеристики не может изменяться участником закупки - В рамках гарантийной поддержки П-МКП Подрядчик должен: – устранять обнаруженные в процессе постоянной эксплуатации дефекты в работе П-МКП в срок не более 5-ти рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); – принимать участие в восстановлении работоспособности П-МКП после сбоев и аварий, вызванных дефектами и недокументированными возможностями подсистемы, выполняя при этом работы, связанные с восстановлением целостности данных и обновлением П-МКП; – вносить изменения в техническую и рабочую документацию на функциональные блоки, на основании выявленных неточностей или обнаруженных недокументированных возможностей подсистемы; – консультировать представителей Заказчика об особенностях реализации П-МКП, в том числе при установке, настройке и пуско-наладке Системы; – давать ответ на заявку Заказчика в течение 1 (Одного) рабочего дня с момента ее поступления - 7 Источники разработки - Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки - Приложение А к Техническому заданию - Таблица А.1 – Описание состава загружаемых данных по мероприятиям Раздел данных Подраздел данных Название атрибута Общая информация об объекте - Наименование Федерального проекта - Инвестпроект - Участок - Длина участка, км Провозная способность, млн. тонн в год план факт Пропускная способность, пар поездов в сутки план факт Максимальная весовая норма поездов, тонн план факт - Наименование мероприятия/объекта - Код объекта - Ответственный исполнитель/ заказчик (контакты) - Субъект Российской Федерации/фактическое (местоположение объекта) - Код ИП - Назначение объекта, основные характеристики объекта (ТЭП) - Предварительная стоимость по ФП (млн. руб.) Ход реализации (Проектирование) Заключен контракт на инженерные изыскания ПД план факт Направление ПД на ГГЭ план по условиям договора факт Получение заключения государственной экспертизы на ПСД план по условиям договора факт стоимость по итогам заключения ФАУ «Главгосэкспертиза России» - Сроки по ПОС Ход реализации (Строительство) Проведение конкурсных процедур на выполнение СМР Объявление торгов (план) Объявление торгов (факт) Заключение контракта на СМР (план) Заключение контракта на СМР (факт) Оформление земельно-правовых отношений* план факт выполнение в % Получено РС план факт Ввод объекта во временную эксплуатацию план факт Получен ЗОС план факт Ввод объекта в эксплуатацию (РВ) план по условиям договора* факт отклонение (дни) - Примечание Обеспеченность машинами и механизмами - план факт - - Строительная готовность (в %) Привлечение трудовых ресурсов, чел. - план факт - - Уровень риска реализации (определяется по наличию отставаний по контрольным точкам, влияющих на срок ввода в эксплуатацию) Объем финансирования в соответствии с ФП (млн. руб.) Год, по которому сформирован отчет Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Сводная бюджетная роспись на отчетную дату - - Значение характеристики не может изменяться участником закупки - Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) - Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства

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

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

ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик»)

1 Общие сведения 1.1 Наименование системы - Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. - - Значение характеристики не может изменяться участником закупки

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

1.3 Основания для выполнения работ - 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; - - Значение характеристики не может изменяться участником закупки

10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010;

17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ - 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - - Значение характеристики не может изменяться участником закупки

11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»;

25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации

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

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

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

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

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

2.2 Цели развития Системы - Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

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

2.3 Состав выполняемых задач - Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей

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

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

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

1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП

3.2.1. Состав используемого ПО - Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. - - Значение характеристики не может изменяться участником закупки

Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ

Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ)

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

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

3.3.2. Информационные объекты - Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) - - Значение характеристики не может изменяться участником закупки

3.3.3. Процессы автоматизации - Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных - - Значение характеристики не может изменяться участником закупки

3.3.4. Взаимодействие участников - Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах - - Значение характеристики не может изменяться участником закупки

4 Требования к Работам - Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы - - Значение характеристики не может изменяться участником закупки

4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре - 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 - - Значение характеристики не может изменяться участником закупки

17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17

Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком.

В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей

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

4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков

№ Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4

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

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

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

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

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

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

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

4.1.6 Требования к транспортабельности - Не предъявляются - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.1.10 Требования к безопасности исходного кода - Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности

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

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

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

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

4.1.14 Требования к численности персонала оператора Системы - Дополнительные требования к численности персонала оператора не предъявляются - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.2 Требования к содержанию работ 4.2.1 Архитектурное решение - 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком

4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур.

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

4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ

4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов

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

4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта)

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

Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации».

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

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

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

4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4 Функциональные требования к блокам функционального контура - Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; - - Значение характеристики не может изменяться участником закупки

– возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных.

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

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

4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов

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

Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/);

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

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

4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией

4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР);

4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

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

4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам

4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных

К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

– возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки)

4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации)

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

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

4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов:

– исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/);

– журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/);

– строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/)

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

4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом

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

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

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

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

– формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы;

– процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта

Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий;

– просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»:

4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи

– доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования);

Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов

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

– журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

№ п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии

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

4.2.5 Общие требования к функционированию - 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ - - Значение характеристики не может изменяться участником закупки

4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02

4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы

4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования - 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления - - Значение характеристики не может изменяться участником закупки

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

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

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

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

5 Состав и содержание работ по развитию АСУ ТК - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) - - Значение характеристики не может изменяться участником закупки

5.1 Состав работ и график их выполнения (календарный план) - 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 - - Значение характеристики не может изменяться участником закупки

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

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

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

3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026

6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации - Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ - - Значение характеристики не может изменяться участником закупки

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

Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный

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

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

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

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

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

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

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

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

7 Источники разработки - Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки

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

Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.)

Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства

- 62.01.11.000 - Этап №3: Опытная эксплуатация. Приемочные испытания ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект ... 1 Общие сведения 1.1 Наименование системы Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. 1.2 Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры - Условная единица - 1,00 - 17 472 052,60 - 17 472 052,60

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект Значение характеристики не может изменяться участником закупки ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») 1 Общие сведения 1.1 Наименование системы Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. Значение характеристики не может изменяться участником закупки 1.2 Наименование Заказчика и Подрядчика Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры Значение характеристики не может изменяться участником закупки 1.3 Основания для выполнения работ 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; Значение характеристики не может изменяться участником закупки 10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010; 17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» Значение характеристики не может изменяться участником закупки 11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»; 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации 1.5 Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 30.06.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего ТЗ (далее – Календарный план) Значение характеристики не может изменяться участником закупки 1.6 Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5.1 настоящего ТЗ, в соответствии с Календарным планом и Контрактом Значение характеристики не может изменяться участником закупки 1.7 Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет. Тестовый стенд для проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний предоставляет Заказчик. Доступ к тестовому стенду Заказчик предоставляет Подрядчику на основании письменного обращения. Требования к предоставляемым вычислительным мощностям должны соответствовать требованиям, указанным в пояснительной записке, представляемой на этапе № 1 работ Значение характеристики не может изменяться участником закупки 2 Назначение и цели развития Системы 2.1 Назначение Системы Основными задачами, решаемыми в настоящий момент системой АСУ ТК, являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов контроля безопасности и устойчивости транспортного комплекса, управления в чрезвычайных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими органами государственной власти, а также гражданами и организациями Значение характеристики не может изменяться участником закупки АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными стратегическими целями развития АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и принятия мер по их устранению и ликвидации последствий 2.2 Цели развития Системы Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки Основными целями выполнения работ являются: – создание среды взаимодействия участников строительства на этапах реализации процесса строительства (реконструкции); – создание единого источника достоверной, непротиворечивой и верифицированной информации для принятия решений на всех управленческих уровнях; – повышение достоверности и прозрачности информации об инвестиционных проектах и программах; – повышение дисциплины формирования и предоставления плановых и отчетных форм; – обеспечение единого информационного пространства инструментам регистрации, хранения, согласования документов-обоснований; – обеспечение инструментов контроля полной стоимости, статей затрат по базовым, текущим ценам и ценам инвестиционного проекта, и физическим характеристикам; – обеспечение формирования графиков, контроля исполнения и сигнализация рисков неисполнения контрольных этапов; – повышение прозрачности процессов и оптимизация взаимодействия между различными участниками реализации инвестиционных проектов. Достижение указанных целей осуществляется для достижения стратегических целей развития АСУ ТК, указанных в пункте 2.1 ТЗ. Основные процессы, автоматизируемые в рамках выполнения Работ: – управление инвестиционными проектами строительства и реконструкции; – управление разработкой и согласование ПИР на всех стадиях реализации проекта; – управление задачами участников проектов строительства и реконструкции; – формирование и согласование исполнительной документации; – формирование и ведение календарно-сетевого планирования; – проведение процедуры строительного контроля; – формирование отчетности 2.3 Состав выполняемых задач Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей 3 Сведения об объектах автоматизации 3.1 Описание объектов автоматизации Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими органами государственной власти, гражданами и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. В соответствии с Аттестатом соответствия требованиям по защите информации АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» Значение характеристики не может изменяться участником закупки 3.2 Текущее состояние объекта автоматизации Текущая архитектура АСУ ТК приведена на рисунке 1. Рисунок 1 – Архитектурная схема АСУ ТК АСУ ТК осуществляет идентификацию и авторизацию посредством ЕСИА. Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3, СМЭВ 4, а также с использованием технологий API и FTP с учетом требований Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России», утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД. АСУ ТК развернута на вычислительных мощностях Головного центра обработки данных ФБГУ «СИЦ Минтранса России». На этапе технического проектирования Подрядчик формирует требования к необходимым вычислительным мощностям для разворачивания ПО, создаваемого в рамках настоящего ТЗ. В текущей конфигурации Подсистема «Мониторинга комплексного плана» (П-МКП) обеспечивает выполнение следующих основных функций: – обеспечение оперативного взаимодействия участников реализации КПМИ в цифровой форме при подготовке, изменении и реализации планов-графиков ФП КПМИ; – визуализация содержащихся в П-МКП данных, представление их в удобном для анализа виде; – ранжирование объектов планов-графиков ФП КПМИ, в соответствии с Методикой ранжирования отдельных мероприятий, включаемых в ФП КПМИ на период до 2024 года ; – мониторинг исполнения планов-графиков ФП КПМИ, включая сбор, обработку, представление данных, необходимых для мониторинга и формирования отчетов на основе данных мониторинга планов-графиков в соответствии с Методическими указаниями по мониторингу и внесению изменений в Комплексный план модернизации и расширения магистральной инфраструктуры на период до 2024 года (транспортная часть) и ФП КПМИ Значение характеристики не может изменяться участником закупки АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи 1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП 3.2.1. Состав используемого ПО Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Значение характеристики не может изменяться участником закупки Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ) 3.3 Объект автоматизации в рамках настоящего Технического задания Предметом автоматизации является объединение в едином информационном пространстве данных по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, в отношении которых предусмотрена реализация мероприятий по строительству (реконструкции) в рамках национальных и федеральных проектов. Объекты автоматизации перечислены далее Значение характеристики не может изменяться участником закупки 3.3.1. Физические объекты Объекты транспортной инфраструктуры, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – автомобильные дороги федерального, регионального, межмуниципального и местного значения; – железнодорожные пути и станции, сопутствующая инфраструктура; – аэродромы и аэропортовые комплексы; – морские и речные порты, причалы, судоходные гидротехнические сооружения. Иные объекты, относящиеся к ведению Минтранса России, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – суда, в том числе аварийно-спасательный и вспомогательный флот; – пункты пропуска через государственную границу Российской Федерации Значение характеристики не может изменяться участником закупки 3.3.2. Информационные объекты Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) Значение характеристики не может изменяться участником закупки 3.3.3. Процессы автоматизации Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных Значение характеристики не может изменяться участником закупки 3.3.4. Взаимодействие участников Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах Значение характеристики не может изменяться участником закупки 4 Требования к Работам Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы Значение характеристики не может изменяться участником закупки 4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 Значение характеристики не может изменяться участником закупки 17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17 Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком. В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей Уровень хранения данных: – распределенные базы данных; – предзаполненный набор справочников, содержащих нормативно-справочную информацию; – отдельно вынесенный базовый функционал, обеспечивающий сохранение и обработку данных. Уровень информационного взаимодействия: – выполнение автоматизированных операций, обеспечивающих подготовку (агрегирование данных) и передачу данных между контурами. Уровень файлового хранения: – распределенная файловая система, обеспечивающая хранение и обработку загруженных в систему файлов. Уровень работы микро- и макросервисов: – запускаемые в асинхронном режиме application instance, нацеленные на выполнение отдельных ресурсоемких задач и использующие минимальный набор внутренних зависимостей, необходимых для выполнения задачи. При проектировании и разработке всех составляющих компонентов следует использовать единую методологию и единые принципы взаимодействия, надежности и управления 4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков № Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4 4.1.2 Требования к режимам функционирования П-МКП по результатам Работ П-МКП должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования должен быть штатный. В штатном режиме все подсистемы корректно и полностью должны выполнять свои функции. Перерывов в работе как П-МКП в целом, так и одного, либо нескольких компонентов, не предусмотрено. Режим регламентного (профилактического) обслуживания должен быть предназначен для проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе П-МКП с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию П-МКП и их периодичность должны быть определены Подрядчиком в процессе выполнения работ по созданию П-МКП. В режиме регламентного (профилактического) обслуживания П-МКП может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода П-МКП в данный режим, должен быть определен Подрядчиком Значение характеристики не может изменяться участником закупки Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ 4.1.3 Показатели назначения В рамках выполнения работ по развитию Системы, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице 3. Таблица 3 – Определения показателей, связанных с количеством пользователей в подсистеме «Мониторинга комплексного плана» (П-МКП) № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечивать Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значение характеристики не может изменяться участником закупки Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице 4. Таблица 4 – Значения показателей количества пользователей подсистемы «Мониторинга комплексного плана» (П-МКП) № Показатель Значение 1 Расчетное количество пользователей 1000 2 Расчетное среднее количество одновременно работающих пользователей 500 Развитие Системы должно быть направлено на достижение следующих описаний ключевых результатов (ОКР), в рамках ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» мероприятия 1 ВПЦТ Минтранса России на период 2026-2028: · «Реализован функционал цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры подсистемы «Мониторинга комплексного плана» АСУ ТК». · «Проведено импортозамещение подсистемы «Мониторинга комплексного плана» АСУ ТК» 4.1.4 Требования к надежности функционирования и доступности для пользователей Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надежность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счет: – обеспечения требуемого уровня квалификации обслуживающего персонала; – регламентации и нормативного обеспечения выполнения работ обслуживающего персонала; – своевременной диагностики неисправностей. Расчетное значение коэффициента готовности АСУ ТК должно составлять не менее 0,95. Планы и процессы обеспечения непрерывности функционирования АСУ ТК должны быть увязаны с перечнем наиболее критических компонентов АСУ ТК, перечнем наиболее важных информационных ресурсов АСУ ТК Значение характеристики не может изменяться участником закупки ПО АСУ ТК должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов АСУ ТК; – сохранение работоспособности ПО при некорректных действиях пользователя; – резервное копирование БД Системы. Средства АСУ ТК по итогам развития должны обеспечивать следующие характеристики надежности при определенном уровне доступности функций: – операционное время: 24x7; – время восстановления работоспособности Системы после отказа или проведения регламентных работы: не более 4 часов; – отказоустойчивость на уровне 99% при единовременном обращении к Системе не менее 10 пользовательских сессий. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи публичных сетей. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Система должна автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом или исполняемых программных кодов Системы либо ее компонент) 4.1.5 Требования по диагностированию Системы Компоненты АСУ ТК должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО. АСУ ТК должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы. Диагностирование должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего ПО Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного ПО серверов Системы; – сбои и нарушения функционирования прикладного ПО серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в ПО диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы Значение характеристики не может изменяться участником закупки 4.1.6 Требования к транспортабельности Не предъявляются Значение характеристики не может изменяться участником закупки 4.1.7 Требования к эксплуатации и техническому обслуживанию Обслуживание Системы должно производиться обслуживающим персоналом. Допускается использование специализированных служб или подразделений на объектах внедрения для обслуживания и ремонта оборудования. При эксплуатации Системы должны использоваться штатные методы защиты от механических, тепловых, электромагнитных и других воздействий, защиты данных, в том числе, от несанкционированного доступа к ним, применяемые у Заказчика. Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Системы. При возникновении неисправностей должно осуществляться оперативное обслуживание Значение характеристики не может изменяться участником закупки 4.1.8 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется Значение характеристики не может изменяться участником закупки 4.1.9 Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего : – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; Значение характеристики не может изменяться участником закупки – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 17, 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 20, 20.14, 25(1) и 25(2) Требований, о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11.02.2013 № 17; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.1.10 Требования к безопасности исходного кода Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО Значение характеристики не может изменяться участником закупки Заказчик предоставляет результаты контрольных проверок, зафиксированных в артефактах сборочного процесса, Подрядчику для устранения в срок до даты завершения исполнения Контракта. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности и т.д., в случае, если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента 4.1.11 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Требования к эксплуатации оборудования Заказчик обеспечивает самостоятельно или с помощью привлеченных сторонних организаций. Для нормальной эксплуатации разрабатываемого ПО должно быть обеспечено бесперебойное питание серверов. При эксплуатации должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации серверов температура и влажность воздуха. Значение характеристики не может изменяться участником закупки 4.1.12 Требования по сохранности информации при авариях При аварийных ситуациях в АСУ ТК должна обеспечиваться сохранность информации. Реализуемые технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т. п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными Значение характеристики не может изменяться участником закупки 4.1.13 Требования к патентной чистоте и патентоспособности 4.1.13.6. В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке) или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия – Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО; – должны передаваться исходный код, дистрибутивы, эксплуатационная и техническая документация. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности, предоставления правообладателям доступа к ПО и т.п.), не предусмотренные Контрактом Значение характеристики не может изменяться участником закупки 4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1.13.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке по соответствующему этапу исполнения контракта. Разработанное ПО поставляется вместе с исходными кодами. 4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности 4.1.13.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.1.13.4. Подрядчик должен подтвердить, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части и иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними 4.1.13.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам 4.1.13.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта 4.1.14 Требования к численности персонала оператора Системы Дополнительные требования к численности персонала оператора не предъявляются Значение характеристики не может изменяться участником закупки 4.1.15 Требования к квалификации персонала Системы, порядку его подготовки и контроля знаний и навыков Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере, к системным администраторам предъявляются следующие требования: – знание основных принципов построения СУБД; – наличие расширенных знаний в области поддержки пользователей; – знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации Значение характеристики не может изменяться участником закупки 4.1.16 Требуемый режим работы персонала оператора Системы Режим работы персонала должен соответствовать действующему законодательству Российской Федерации (РФ) и обеспечивать работоспособность Системы согласно требованиям, предъявленным настоящим ТЗ. Должна быть учтена возможность сменного режима работы персонала Системы. При этом должна учитываться возможность круглосуточного подключения к работам специалистов, обеспечивающих функционирование Системы (администраторов и специалистов по техническому обслуживанию), для решения проблем по обеспечению работоспособности информационных ресурсов Системы Значение характеристики не может изменяться участником закупки 4.1.17 Требования к эргономике и технической эстетике Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме, возможно, системных сообщений), должны быть на русском языке. Все экранные формы должны иметь текстовую справку, в которой должна быть описана инструкция по работе с данной экранной формой. На всех экранных формах при выполнении операций должна быть выведена индикация, которая информирует пользователя о статусе выполнения операции. Система должна обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введеенных значениях Значение характеристики не может изменяться участником закупки Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя манипулятора типа «мышь», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов. Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских веб-интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АСУ ТК должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АСУ ТК. Визуальное представление элементов пользовательского интерфейса АСУ ТК и состав отображаемой информации подлежат согласованию Заказчиком в процессе выполнения работ по модернизации Системы 4.2 Требования к содержанию работ 4.2.1 Архитектурное решение 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 Значение характеристики не может изменяться участником закупки 4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком 4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур. 4.2.2 Требования к масштабируемости и расчету мощностей 4.2.2.1 Модульность и горизонтальное масштабирование Архитектура ПО должна быть модульной и поддерживать горизонтальное масштабирование (scale-out) контуров без изменения исходного кода приложения. Функциональный контур масштабируется путем создания копий и подключения к сервису передачи агрегированных данных в информационно-аналитический контур. При этом могут применяться стратегии административного, функционального или географического разделения пользователей по экземплярам контура, в том числе с помощью настройки конфигурации приложения каждого экземпляра. Критичные компоненты, такие как серверы приложений, веб-сервисы и обработчики очередей, должны быть спроектированы как независимые, stateless (бессостоятельные, не сохраняющие состояние на самом сервере) сервисы. Хранение состояний приложения возможно с использованием СУБД. Это позволит увеличивать производительность и отказоустойчивость за счет добавления новых экземпляров сервисов в пул под нагрузкой балансировщика Значение характеристики не может изменяться участником закупки 4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ 4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов 4.2.3 Требования к функциональным блокам информационно-аналитического контура Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». Значение характеристики не может изменяться участником закупки Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов. Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Освоено» должен отображать освоение (принято) в млн. руб. с разделением по годам, с фильтрацией по признакам: – всего нарастающим итогом с начала реализации (до утв. паспорта ФП); – всего нарастающим итогом после утверждения паспорта ФП; – всего с начала отчетного года; – всего с начала отчетного месяца; – всего по контракту/контрактам. Виджет «Контрактация» должен отображать плановый объем финансирования по контракту/ контрактам в отношении к «Законтрактовано в млн. руб» с нарастающим итогом с начала отчетного года. Необходимо реализовать фильтрацию по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Контрактация по контрактам» должен отображать сводную информацию о видах и количестве контрактов, которые были заведены. Виджет «Обеспеченность машинами и механизмами» должен отображать наличие машин и механизмов по плановому и фактическому значению в разрезе объектов. Виджет «Динамика по трудовым ресурсам (чел.), машинам и механизмам (в ед.)» должен отображать привлечение трудовых ресурсов по плану-факту с возможностью фильтрации по периоду. Виджет «Строительная готовность объекта» должен отображать готовность объекта в процентах. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Паспорт объекта должен содержать следующие вкладки: – «Паспорт» (информация и параметры объекта, участники строительства, сведения о затратах с фильтрацией по бюджетам, проблемные вопросы); – «Показатели» с возможностью редактирования; – «Финансирование» (сведения о выделенных и доведенных д\с в разбивке по бюджетам); – «Контракты» (сведения о заключенных контрактах по объекту с возможностью редактирования); – «Строительный контроль» (количество выявленных недостатков по типам; – «Подробные сведения о выявленных недостатках» с возможностью редактирования; – «Проблемные вопросы» (сведения о проблемных вопросах в разбивке по типам); – «Задачи» (доступ к функциональному блоку по работе с задачами с возможностью создания новых задач); – «Фотогалерея» (изображения с площадки строительства объекта). Необходимо реализовать виджеты, отображающие аналитическую информацию о количестве контрольных точек (далее - КТ), отражающих ход реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, относящихся к ведению Минтранса России. Все виджеты данной группы должны иметь следующие фильтры по: – национальным и федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – статусу достижения; – видам работ (проектирование, получения заключения государственной экспертизы проектной документации, строительно-монтажные работы, ввод в эксплуатацию и др.) Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов должна раскрываться таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ. Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и их срок . Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о соблюдении ранее установленного срока, выполненных ранее срока, выполненных в срок, не выполненных в срок (срок истек), не выполненных (срок не наступил). Виджет «Контрольные точки, риски» должен отображать общее количество объектов, количество завершенных объектов, количество объектов с высокой степенью риска, со средней и умеренной/ отсутствующей. При нажатии на количество объектов должна открываться таблица с объектами и контрольными точками, отображающими текущую КТ, план и факт по каждой контрольной точке с подсвечиванием отставания соответствующим цветом. Зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев; Необходимо реализовать виджет, который отображает аналитическую информацию о текущих и прогнозных рисках и их влиянии на показатели национальных и федеральных проектов с возможностью выбора параметра (мощности), влияние на который оказывают объекты, и добавления фильтров по: – федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств 4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.3.4 Функциональный блок загрузки данных Функциональный блок предназначен для обеспечения информационного обмена со смежным контуром и должен обеспечивать получение (загрузку) актуальных данных по проектам, объектам, их финансированию и контрольным точкам исполнения. Данные должны сохранятся в функциональном блоке в агрегированном (сводном) виде и использоваться в качестве источника информация для построения виджетов аналитической панели, а также отчетов. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных; – преобразования данных; – сохранения данных; – хранения истории запусков. Должны быть реализованы следующие стратегии загрузки: – ручная загрузка данных, предоставленных в файлах; – автоматическая загрузка данных из смежного контура. Автоматический режим подразумевает под собой фоновую регулярную загрузку сводной информации, собранной на основе актуальных данных, вводимых в функциональные блоки Ручной режим загрузки должен обеспечивать возможность загрузки данных по шаблону. Файл для загрузки должен быть в формате *xlsx. Данные могут предоставляться как в полном объеме шаблона, так и в частичном. Функция преобразования данных из файла формата xlsx должна использовать следующие стратегии: – валидация данных на соответствие шаблону; – применение функций преобразования к отдельным полям источника данных, такие как приведение типов, преобразование формата даты; – агрегация данных по выбираемым категориям; – применение функций преобразования для получения вычисляемых значений; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция хранения истории запусков должна фиксировать следующую информацию: – дата и время загрузки; – название источника; – статус загрузки; – сообщение об ошибках (при наличии). При помощи шаблона предполагается загрузка следующей сводной информации по объектам строительства: – наименование объекта строительства, федерального проекта, инвестиционного проекта, указание местоположения и пр. основные характеристики; – общая информация об объекте, включающая в себя плановые и фактические показатели с детализацией по годам за 5 лет; – плановые и фактические показатели хода реализации, описывающие сроки достижения контрольных точек этапов проектирования и строительства; – плановые финансовые показатели с детализацией по годам и источникам финансирования, включающие в себя объем финансирования и план освоения; – плановые и фактические показатели по контрактации; – плановые и фактические показатели по обеспеченности машинами и механизмами; – плановые и фактические показатели по привлечению трудовых ресурсов; – информация о строительной готовности; – информация об уровне риска реализации и необходимым мерам. Данные, переданные в функциональный блок посредством ручной загрузки отчета, должны сохраняться как в сводном виде, подходящем для показа в аналитических панелях, так и фиксироваться в виде пакета (отчета) с сохранением времени загрузки и автора В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.3.1 АРМ Сотрудника Функциональный блок должен обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников: – сводной информации, полученной из функционального контура; – информации, сформированной в иных системах (программных продуктах) и загруженной с помощью импорта файла формата xlsx установленной структуры. Информация, собираемая и показываемая в АРМ Сотрудника, должна иметь возможность быть представленной как в рамках конкретного объекта, так и в рамках группы объектов, заданной набором фильтров. В состав данной информации должны входить показатели исполнения объекта, финансовые показатели, фиксация прохождения контрольных точек реализации исполнения. Для показа информационной сводной панели необходимо разработать функциональный блок настраиваемых аналитических панелей - компонент графического представления данных для отображения набора настраиваемых виджетов с возможностью создания (настройки) панелей для анализа информации по различным бизнес-процессам. Для формирования и выгрузки аналитических данных в форме табличного отчета необходимо разработать функциональный блок отчетности. Данный компонент должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов и достижении ключевых событий. Для сбора информации, необходимой для формирования аналитических панелей и отчетов, требуется разработать функциональный блок загрузки данных. Компонент должен обеспечивать регулярную автоматическую загрузку данных из контура функционального уровня в сводном агрегированном виде, достаточном для показа на панелях и для формирования отчетов. Кроме того, в компоненте должна быть предусмотрена возможность ручной загрузки данных в подготовленном формате 4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта) Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер должен представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также требуется реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания; – переход в информационный паспорт объекта во вкладке таблицы. 4.2.4 Функциональные требования к блокам функционального контура 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. Значение характеристики не может изменяться участником закупки Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных из файлов формата xml; – преобразования данных; – сохранения данных; – фиксация выполненных действий по созданию/изменению в истории событий. Функция преобразования данных из файла формата xml должна использовать следующие стратегии: – валидация файла на соответствие xsd-схемам, утвержденным Минстроем России и опубликованным на официальном сайте как актуальные; – валидация данных файла на соответствие форматам ожидаемых данных и данным, уже имеющимся в П-МКП, в т.ч. проверка наличия и доступности пользователю объекта строительства, юридических лиц, указанных в документе. Полный набор критериев валидации должен быть разработан на этапе № 1 Календарного плана; – применение функций преобразования к отдельным полям источника данных, таким как приведение типов, преобразование формата даты; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования. Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция сохранения истории событий должна фиксировать в т.ч. следующую информацию: – дату и время события; – название события; – автора события; – сохраняемые или изменяемые данные Данные, полученные на основании загруженного файла, должны сохраняться в качестве документов или записей, соответствующих данному документу, с фиксацией всей информации, содержащейся в файле (в т.ч. объект строительства, юридические и физические лица, информация об объемах, суммах и пр). Файл формата xml, на основании которого создан документ или запись, должен быть прикреплен к карточке этой записи и доступен для скачивания. Документы и записи, созданные посредством загрузки данных из файлов xml, должны быть доступны загрузившему их пользователю в соответствующей вкладке АРМ Подрядчика, а также сотрудникам Заказчика, имеющим доступ к объекту строительства. Функциональный блок должен поддерживать возможность загрузки файлов с измененными данными по документу (новые версии документа) с возможностью связать созданный документ с его предыдущими версиями или обновить (заменить) данные в уже существующем документе без создания новой версии. Во втором случае файл, содержащий данные об изменениях, должен быть прикреплен в качестве новой версии исходного файла. В функциональном блоке должна быть возможность разграничения прав на загрузку отдельных видов документов, определяемая настройкой прав пользователей и ролевой моделью. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов В рамках функционального блока требуется разработать следующий набор вкладок: – список доступных Подрядчику объектов с возможностью фильтрации по общей информации об объекте (тип, вид статус, адрес объекта, участники реализации и др.) и просмотра краткой информации по каждому из них. Общий перечень данных в карточке не должен превышать описанный в разделе функциональный блок «Информация»; – вкладки с реестрами загруженных документов с возможностью группировки по типам и объектам, с возможностью перехода к карточке документа; – карточки отдельных документов, содержащие в себе основную информацию о документе и его участниках, версию документа, прикрепленный файл в формате xml, на основании которого документ был создан, список замечаний, выданных по документу, возможность выполнения действий по согласованию и подписанию с использованием функционального блока для ведения электронного документооборота (СЭД); – вкладка загрузки данных из файлов формата XML по схемам, определенным Минстроем России для передачи документов в электронном виде и опубликованным на официальном сайте; – список пользователей, являющихся представителями Подрядчика и имеющих доступ к АРМ Подрядчика и конкретным объектам в нем, с возможностью управления доступом, подключением новых пользователей и блокировкой ранее подключенных. Необходимо предусмотреть возможность для администратора от Подрядчика управлять доступом отдельных пользователей к конкретным объектам строительства; – список аккаунтов для взаимодействия с внешней системой электронного документооборота, в случае использования Удостоверяющего центра для подписания документов с использованием КЭП (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); 4.2.4.4.3. Требования к созданию виджетов Необходимо разработать следующий функционал: – реализовать возможность точечной настройки аналитических виджетов по дате формирования данных (при необходимости); – выполнить возможность непосредственного перехода от информации на виджете дашборда к источникам данных; – реализовать возможность пользовательской настройки отображения и группировки виджетов 4.2.4.2 АРМ Заказчика Функциональный блок АРМ Заказчика должен включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны Заказчика доступом к АРМ Подрядчика для сотрудников Подрядчиков. Функционал должен обеспечивать следующие возможности: – просмотр списка новых объектов строительства; – возможность перехода к карточке объекта, возможность добавления новых объектов; – просмотр списка юридических лиц, выступающих Подрядчиками на проектах, возможность просмотра информации о них, добавления новых, редактирования и удаления созданных ранее; – возможность создания АРМ Подрядчика для юридических лиц, выполняющих работы на объекте; – просмотр списка пользователей, являющихся представителями подрядчика, управление их доступом к АРМ Подрядчика, возможность добавления новых и блокировки неактуальных (уволенных, прекративших свою деятельность по проекту). Функциональный блок должен разрабатываться в интерфейсах, аналогичных АРМ Подрядчика. Информация представляется в виде вкладок, осуществляющих: – работу с объектами строительства; – работу и управление Подрядчиками; – настройку АРМ Подрядчика; – управление пользователями АРМ Подрядчика; – просмотр и работу с предоставленными документами через механизм загрузки в формате XML. Объем данных, выводимых в каждой вкладке, регулируется правами доступа пользователя-администратора Заказчика к объектам и юридическим лицам. Доступ к АРМ Заказчика в целом и к конкретным вкладкам в нем, должен управляться настройкой прав пользователя. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана – возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки) 4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией 4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9.2. Требования формированию плана освоения. Раздел функционального блока «ГПР» - вкладка «План освоения» Необходимо иметь возможность учитывать все виды ресурсов: материалы, машины и механизмы, рабочую силу, а также планировать их потребление. Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» представлены в таблице 7. Таблица 7 – Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» № п/п Функциональность вкладок 1 Должен формироваться план освоения в объемах и деньгах на основании графика работ с возможностью детализации по настраиваемым периодам распределения, настраиваемым типом расчета. В рамках плана освоения должна отображаться информация по плановым, фактическим показателям, показателям по директивному плану и закрывающим документам, а также показатели по отклонениям (план-факт, план-закрыто, факт-закрыто). 2 Должен отображаться ресурс типа -материалы. 3 Должен отображаться ресурс типа -машины и механизмы. 4 Должен отображаться ресурс типа -рабочая сила и кадры. 5 Должен позволять формировать накопительную ведомость Также необходимо настроить систему уведомлений на почту ___@___ в системе. В уведомлении указываются сведения: 1) об объекте капитального строительства с указанием адреса (местоположения) объекта и времени проведения контрольных мероприятий; 2) о предъявляемых к освидетельствованию видов (этапов) работ, конструкций с указанием осей, пикетов, рядов, отметок или иных привязок мест расположения объекта освидетельствования и об участниках строительства, привлекаемых для выполнения указанных работ; – формирование аналитической информации по недостаткам; – отображение типовых нарушений со ссылкой на нормативные правовые акты; – замещение инспектора строительного контроля; – добавление недостатков, которые устранены в ходе проверки; – привязка недостатков к элементам BIM моделей; – привязка проверок к ПД/РД/ИД; – привязка недостатков к элементам графика производства работ; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.4.2. Требования к отображению объекта на интерактивной схеме Функционал должен включать отображение объектов на интерактивной схеме РФ, расположенной на аналитической панели – дашборд. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта). Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также необходимо реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры); – годам; – Заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.14 Функциональный блок ведения договоров «Управление проектом» Необходимо разработать следующий функционал: – формирование категорий контрактов; – формирование контрактов с указанием статусов, основных показателей и условий, предусмотренных контрактом (обязательства, авансы, дополнительные соглашения, гарантийные удержания и др.); – формирование и учет платежей по контрактам с привязкой к типу, план/факт, не законтрактовано (год) и типу бюджета; – формирование дополнительных соглашений к контракту с автоматическим изменением суммы, плановой даты начало/окончания контракта; – аналитика контрактов по текущим статусам, видам и типам выполняемых работ на объекте. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.8 Функциональный блок «Информация» Данный функциональный блок содержит требования к функциям ведения карточек проектов и программ. В рамках выполнения Работ необходимо организовать ввод, обмен и хранение, и актуализацию данных по проектам и программам. Карточка объекта/программы должна содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и Подрядчиков по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков). Виды информации: – общая информация об объекте строительства (тип, вид статус, адрес объекта, участники реализации и др.); – данные по освоению денежных средств (кассовое исполнение, оплачено по контрактам, риск неосвоения лимитов); – отображение всех показателей объекта (технико-экономические показатели, статус реализации, градостроительная проработка и др.); – информация по финансированию объекта (выделение и доведение денежных средств); – информация по контрактам объекта; – информация по вопросам, возникающим в ходе реализации; – данные по выполнению задач по объекту; – фотогалерея; – видеонаблюдение в режиме реального времени. При открытии карточки объекта должен открываться функциональный блок «Информация», в котором указывается сводная информация по объекту, разделенная по вкладкам согласно таблице 5 – Виджет «Текущая аналитика СМР по ГПР» должен отображать данные по выполненным работам и освоенным средствам. Учитываются только данные из актуальных ГПР стадии СМР; – Виджет «Мониторинг исполнения ГПР, СМР» должен отображать сводную информацию о сроках исполнения плановых графиков ГПР по работам СМР (в сравнении с фактическими датами начала/окончания работ в ГПР); – Виджет «Мониторинг строительного контроля» должен отображать информацию о недостатках, выявленных в ходе проверок инспектором строительного контроля по всем объектам базы; – Виджет «Недостатки» должен отображать информацию о количестве недостатков, выявленных в ходе проверок строительного контроля в разбивке по их текущему статусу; – Виджет «Качество исполнительной документации» должен отображать количество документов, находящихся на согласовании, количество подписанных ЭП и количество выданных замечаний к документации; – Виджет «Стадии реализации (текущие)» должен отображать количество объектов по текущим стадиям реализации строительства, указанным в функциональном блоке «График производства работ» 4.2.4.4.3.3. Виджеты по тематике «Управление проектами» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Статус объектов проектирования и строительства» должен отображать статус объектов; – Виджет «Актуальные вопросы (количество, статусы)» должен отображать количество и статусы по актуальным вопросам по объектам; – Виджет «Технико-экономические показатели реализуемых объектов» должен отображать сводную информацию об основных технико-экономических показателях объектов; – Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов раскрывается таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ; – Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и срок которых не наступил. Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о выполненных ранее срока, выполненных в срок и «Не выполнено. срок истек», «Не выполнено. Срок не наступил» 4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам Необходимо разработать следующий функционал: – автоматическое формирование плана освоения на основании сформированного графика с отображением данных, введенных в ГПР в табличной форме по различным разрезам (стоимости и объемы работ) с возможностью выбора детализации отображения по временным периодам (день / неделя / месяц / квартал / год) и типу отображения (раздельно или накопительно) и возможностью отображения различных показателей – работы / материалы / машины и механизмы / рабочая сила и кадры; – автоматическое создание плана освоения денежных средств и физических объемов выполняемых работ в разрезах рабочей силы (чел-час), ресурсов машин и механизмов (маш-час), материалов (ед. изм.); – возможность настройки отображения показателей, а также настройки диапазона дат; – формирование графика фактического освоения денежных средств и объемов по кварталам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.10 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Необходимо разработать следующий функционал: – реализация многоуровневого списка категорий документов ПИР с предустановленными значениями категорий и возможностью добавлять категории самим пользователем в случае необходимости; – наличие предустановленных шаблонов печатных форм документов «Задание на проектирование» и «Задание на инженерные изыскания», возможность выгрузить из документа в виде текстового документа; – реализация процедур согласования и подписания с помощью ЭП документов «Задание на проектирование» и «Задание на инженерные изыскания», «Программа инженерных изысканий» с отображением статуса согласования и подписания соответствующего документа; – возможность сформировать шаблон согласования и указание информации требуется ли наличие предыдущего согласования для этого уровня для выполнения процедуры согласования; – ввод, сортировка и хранение ИРД, проектной и рабочей документации в виде вложенных файлов документации ПИР; – согласование проектной документации с отображением статуса; – формирование и ведение реестров ИРД, проектной и рабочей документации; – возможность формирования документов с сохранением версий для отслеживания изменений проектной и рабочей документации; – реализация механизма работы пользователей с замечаниями к каждому отдельному документу ПИР, ДПТ; – процедура устранения замечаний исполнителем путем возможности внесения в карточку документа в разделе работы с замечаниями ответа о результатах работы над замечанием, включая прикрепления откорректированного документа (если требуется); 4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации) Также на данном дашборде необходимо отобразить: – столбчатую горизонтальную диаграмму «Бюджетные обязательства/ Касса по годам», в которой должны отображаться данные показатели в разрезе по годам. Ниже должна быть отображена таблица с данной информацией; – столбчатую горизонтальную диаграмму «Авансы», отображающую информацию на текущий год: 1) всего аванса по контракту; 2) раскассировано аванса (сумма, которую Подрядчик может потратить со счета авансовых средств. Данные поступают от Подрядчика в виде сведений об операциях для утверждения. Источник данных – система «Электронный бюджет» (можно выгрузить в виде отчета в формате *xls); 3) выплачено аванса (фактическая сумма, перечисленная Подрядчику по выставленным им счетам. Данные поступают из бухгалтерии и также могут быть получены из «Электронного бюджета»); 4) остаток к выплате (показатель рассчитывается как разница между стоимостью контракта, выплаченного аванса и оплаты по КС-2 (актам выполненных работ); 5) зачтено аванса (часть суммы аванса, которая закрывается (засчитывается) при выполнении работ и подписании актов по КС-2 (акты выполненных работ). Таким образом, сумма к оплате по новым актам уменьшается на размер зачтенного аванса); 6) неотработанный аванс (сумма перечисленного аванса, которая еще не закрыта (не зачтена) актами выполненных работ (КС-2), то есть это разница между выплаченным авансом и суммой, которая уже была зачтена); – кольцевую диаграмму «Работы», с информацией по: 1) выполненным работам; 2) остатку к выполнению 4.2.4.4.3.7. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по нескольким объектам из направления» Данный дашборд должен отображать таблицу «светофор» со списком всех объектов по направлениям и со следующими столбцами: – номер по порядку; – наименование объекта; – подрядчик (если договор расторгнут, то необходимо отобразить статус и дату, также если договор планируется расторгнуть или он в процессе расторжения); – стоимость объекта (млрд); – дата начала; – дата завершения; – готовность. Объекты должны быть распределены в таблице и окрашены в соответствующие цвета в зависимости от риска реализации объекта. При наличии риска реализации объекта строка с наименованием объекта должна окраситься в красный, при наличии умеренного риска - в желтый, при отсутствии риска - в зеленый). Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана – формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы; – процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/) 4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий; – просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»: 4.2.4.16 Функциональный блок для ведения электронного документооборота Необходимо разработать инструмент для согласования документов, связанных с реализацией проектов. Требования к разрабатываемому функционалу функционального блока «СЭД»: – работа в СЭД с такими типами документов как: письма, контракты, закупочная документация, проектная/рабочая/исполнительная документация, соглашения, отчеты, первичные документы, приказы, протоколы, распоряжения, положения, служебные/докладные/пояснительные записки, аналитические справки, доверенности. Справочник типов документов должен быть открытый и при необходимости дополняемый; – обеспечение действий Пользователя в СЭД с документами внутреннего и внешнего, документооборота: делегирование, согласование, перенаправление, многостороннее согласование, многостороннее подписание. Реализовать возможность процедуры формирования маршрутов для согласования/подписания документов; – отображение в экранной форме Пользователя в СЭД таких параметров для каждого обрабатываемого документа, как: отправитель и получатель документа, заголовок документа, дата документа, автор документа, тип и статус обрабатываемого документа, крайний срок выполнения связанной с документом задачи. Реализовать возможность фильтрации по указанным параметрам для перечня обрабатываемых Пользователем документов; – формирование документов. Реализовать возможность устанавливать взаимосвязи создаваемых документов с уже существующими в СЭД; возможность формировать приложения к письмам для различных типов файлов, размещенных в т.ч. на ПК Пользователя; поиск по наименованию/ заголовку документа в СЭД по произвольному вводу символов для существующих в СЭД документов; содержать «Тэги» для быстрого поиска созданного письма в системе; возможность указывать метки «прочитано», «не прочитано» для входящей документации; возможность настройки Пользователем на экранной форме СЭД требуемых для отображения параметров; – наличие истории документооборота, сохраняющего записи о всех событиях и их авторах в отношении каждого документа; – интеграция СЭД с вкладкой Планировщик задач, разделом «внутрисистемная почта» и разделом «уведомления». Организация списка документов: – создание раздела «Документы» в АРМ Подрядчика в соответствии с персональными возможностями доступа пользователя к документам; – ведение списка документов с разбивкой по процессам (этапам) и статусам документа: – карточка документа – этап для формирования карточки документа; – согласование – этап для согласования карточки документа с выделением следующих статусов: 1) на согласовании (получено согласование не от всех подписантов); 2) отменено инициатором (маршрут согласования снят инициатором); 3) согласовано (всеми подписантами); 4) отказано (получен отказ хотя бы от одного подписанта); – хранение документов с завершенным или отклоненным согласованием, организованно списком записей справочника, с предоставлением в табличном или ином виде. Должна быть реализована возможность поиска по атрибутам среди документов, доступных к просмотру: – наименование документа; – тип документа; – инициатор; – по связям с сущностями. Должна быть реализована возможность фильтрации документов по атрибутам, по этапам и статусам, по признаку «Я исполнитель», «Я инициатор», «Требует действий» Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов 4.2.4.13 Функциональный блок ведения строительного контроля Необходимо разработать следующий функционал: – отражение результатов проведения инспекционной деятельности (проверки); – автоматическая генерация инспекционных документов (акт проверки и предписания) на основании зафиксированных недостатков; – работа с материалами фото и видеофиксация недостатков с возможностью сформировать отчеты о проведенных проверках и количестве выявленных недостатков; – формирование актов об устранении недостатков; – подписание актов проверки, актов инспекционного контроля, предписаний об устранении недостатков/о приостановке работ, отчета по устранению нарушений (с возможностью приложения документации, отправки отчета на почту), а также актов устранения недостатков; – формирование отчета по установленной форме; – разработка программы проведения инспекционного контроля по форме; – отображение статусов карточек документов и недостатков; – автоматическое направление участникам Проекта уведомлений о выявленных недостатках; – вызов инспектора строительного контроля на Объект (Уведомление о необходимости проведения СК на объекте оформляется на официальном бланке организации Генподрядчика. Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; – возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи – доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования); – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана № п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии 6 Должна содержать таблицу с информацией из графика производства работ о планировании и расходовании средств и ресурсов в рамках процесса строительства. В плане должно отображаться распределение стоимостей по периодам в разрезе стоимостей или объемов работ. 7 Должна иметь возможность формирования суточного графика работ в диапазоне дат с возможностью подневного ввода фактически выполненного объема. 8 Должна быть возможность сравнения версий, имеющих связи между собой Необходимо разработать следующий функционал: – возможность формирования графика производства работ по проекту, в том числе на основании загруженных смет; – возможность формирования сущностей типа «запись ГПР», «Суммарная запись ГПР», «веха»; – возможность ручного добавления, удаления и перемещения по структуре работ в графике; – формирование зависимостей между работами в ГПР с установкой временных задержек; – возможность редактирования внесенного этапа работ; – назначение ответственных и исполнителей на конкретные работы графика, возможность делегирования работ; – возможность полного или частичного делегирования графика в другие версии; – возможность полуавтоматического переноса фактических показателей из делегированной версии в основную; – поддержка версионности и стадийности графиков; – возможность формирования директивной версии графика (базового плана) и заполнения новой версии ГПР на ее основании; – возможность копирования версии ГПР; – возможность сравнения связанных версий графиков между собой; – автоматический расчет критического пути с возможностью отображения только тех работ, которые принадлежат критическому пути; – автоматический расчет прогнозных сроков выполнения работ на основании динамики фактического выполнения работ; – настройка визуального отображения диаграммы Ганта; – возможность удалить этап работ из графика; 4.2.4.4.3.5. Виджеты по тематике «Отображение аналитической информации по объектам и направлению на панели руководителя проекта» Группа виджетов должна отображать текущие показатели по объекту направления. У группы виджетов должен быть предусмотрен фильтр по направлениям (воздушный транспорт, железнодорожный транспорт, морской транспорт, речной транспорт): – стоимость контракта; – дефицит (отображает разницу между доведенными лимитами и стоимостью объекта по ССР); – непогашенный аванс (разница между суммой выданного аванса и погашенного по КС-3); – банковская гарантия с указанием даты завершения (из контрактов); – строительная готовность объекта, отображаемая в процентах, и динамика за неделю по задействованным трудовым ресурсам (чел.) и машинах и механизмах (в ед.); – характеристика объекта; – эффекты, которые оказывает объект строительства; – необходимые решения; – ход исполнения; – фотография объекта. Также по объекту из направления должна отображаться таблица с диаграммой Ганта со столбцами: – номер по порядку; – наименование объекта; – длительность (дней); – начало (дата); – окончание (дата); – диаграмма с разделением по кварталам. Виджет «Отчет по объекту» должен содержать три окна: – в первом окне – «Эффект от реализации»; – во втором окне – «Информация об объекте/Проблемные моменты» со следующим перечислением: 1) поле «Заключен ГК» (необходимо указать юридическое лицо, с которым заключен контракт), далее необходимо показать вид работ из контракта, дату заключения договора и номер контракта; 2) отображение информации о текущей контрольной точке объекта и плановой дате; 3) информация по контракту (дорожная карта); 4) дата ввода объекта в эксплуатацию с комментарием); 5) поле «Виды работ»; 6) изменения количества рабочих/техники с разбивкой по месяцам с даты начала СМР; – в третьем окне – «Предложения по решению проблем» 4.2.5 Общие требования к функционированию 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ Значение характеристики не может изменяться участником закупки 4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02 4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы 4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана 4.2.5.3 Требования к обмену сообщениями В рамках выполнения Работ реализуется встроенный мессенджер, позволяющий обмениваться сообщениями между пользователями АРМ. Требования к разрабатываемому функционалу: – создание персональных чатов из списка пользователей из раздела мессенджера; – создание групповых чатов из раздела мессенджера; – возможность отправки текстовых сообщений и файлов; – поиск по списку чатов; – возможность удаления созданного чата; – корректировка перечня участников группового чата; – индикация групповых чатов в списке 4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления Значение характеристики не может изменяться участником закупки 4.3.5 Требования по применению систем управления хранилищами и базами данных Для хранения данных должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – наличие сертификата соответствия ФСТЭК России требованиям по защите информации, предъявляемым к системам управления базами данных не ниже 5 класса защиты; – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологической в инфраструктуре Заказчика. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика. 2) Допускается использование только кластеризованных баз данных. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре Заказчика. 3) Решение должно быть отказоустойчивым. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов. 4) Любые соединения, устанавливаемые решением, должны быть защищенными*. Примечания: 1 Защищенные соединения, выходящие за пределы контролируемой зоны, должны быть защищены с помощью программных и/или программно-аппаратных шифровальных (криптографических) средств, сертифицированных ФСБ России (далее – СКЗИ). 2 Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД; 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. Использование учетных записей с административными полномочиями не допускается 4.3.2 Требования к организации хранилища данных Для хранения информации должна использоваться СУБД с возможностями распределенного хранения данных по кластерным узлам. СУБД предоставляется Заказчиком после завершения этапа № 1 Календарного плана. Структура БД должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в БД Системы. При проектировании структуры БД для хранения данных необходимо провести анализ реализованной структуры БД для П-МКП в целях использования в создаваемых АРМ. В результате анализа Подрядчик обязан представить Заказчику в Пояснительной записке описание структуры БД для функционирования АРМ с указанием переиспользуемых и вновь создаваемых таблиц БД. Информация должна размещаться в БД по возможности в нормализованной форме. Допускается использование дополнительных ненормализованных структур данных для повышения производительности. Допускается размещение отдельных параметров конфигурации во внешних конфигурационных файлах. Допускается размещение данных в нереляционных СУБД в случаях, предусматривающих очевидную выгоду в производительности, оптимизации требуемого места для хранения данных или необходимых вычислительных ресурсах по согласованию с Заказчиком. Полный перечень используемых программных решений должен быть определен Подрядчиком и согласован Заказчиком на этапе № 1 Календарного плана 4.3.4 Требования к информационному обмену между компонентами Системы Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет 5 Состав и содержание работ по развитию АСУ ТК В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) Значение характеристики не может изменяться участником закупки 5.1 Состав работ и график их выполнения (календарный план) 2 Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Сопроводительным письмом предоставлены Заказчику: Исходные коды разработанного (передаваемого) программного обеспечения; Дистрибутивы разработанного (передаваемого) программного обеспечение; Инструкция по сборке; Паспорт П-МКП; Описание П-МКП; Руководство администратора; Руководства пользователей на каждый АРМ, включая рекомендуемые характеристики к ПК для АРМ; Документы по испытаниям в составе: - Программа и методика предварительных испытаний; - Протокол предварительных испытаний; - Программа и методика опытной эксплуатации; - Акт ввода в опытную эксплуатацию; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Значение характеристики не может изменяться участником закупки 3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Сроки, установленные Календарным планом для каждого подпункта в рамках этапов, согласно таблице 11, включают подготовку, согласование, утверждение (для тех документов, в отношении которых требуется согласование или утверждение) отчетных, технических, рабочих документов с Заказчиком. Досрочная сдача результатов допускается по согласованию с Заказчиком. Сокращение периода (длительности) проведения опытной эксплуатации недопустимо. График выполнения работ по развитию АСУ ТК приведен в таблице 11. Таблица 11 – График выполнения работ по развитию АСУ ТК № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа Ожидаемые результаты работ 1 Техническое проектирование. 1.1. Разработка частного технического задания Начало: с даты заключения контракта Окончание: не позднее 19.01.2026 Сопроводительным письмом предоставлены Заказчику: Частное техническое задание. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 1.2. Разработка технического проекта Начало: 19.01.2026 Окончание: не позднее 26.01.2026 Сопроводительным письмом предоставлены Заказчику: Технический проект в составе: - Описание архитектуры системы; - Пояснительная записка, включая описание автоматизируемых функций; - Описание программного обеспечения; - Описание информационного обеспечения; - Ведомость технического проекта; - Ведомость машинных носителей информации; - Руководство по безопасной разработке программного обеспечения. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу) 6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ Значение характеристики не может изменяться участником закупки 6.2 Виды, состав, объем и методы испытаний и его составных частей В случае выявления ошибок в ПО П-МКП при проведении предварительных испытаний, Подрядчик должен их устранить до начала момента проведения опытной эксплуатации. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки). Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены Подрядчиком в документе «Программа и методика опытной эксплуатации». Программа и методика опытной эксплуатации должна быть утверждена Заказчиком до проведения опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» (с приложением журнала опытной эксплуатации) и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации, подтверждающий готовность П-МКП АСУ ТК и ее допуск к приемочным испытаниям Значение характеристики не может изменяться участником закупки Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный Результаты проведения предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от ТЗ оформляются как недостатки работ. Прочие недостатки могут документироваться как рекомендации. Наличие рекомендаций не влияет на процесс передачи П-МКП АСУ ТК в эксплуатацию. В случае значительного отклонения П-МКП АСУ ТК от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены или расширены Заказчиком. По результатам выполнения этапа № 3 должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии и сроки проведения испытаний. Испытания проводятся на площадке, указанной в программе и методике соответствующих испытаний, опытной эксплуатации. В состав комиссии включаются ответственные лица Заказчика и Подрядчика, а также, при необходимости, специалисты иных внешних организаций (например, экспертных), привлекаемые Заказчиком. Подрядчик обязан уведомить Заказчика о готовности к проведению испытаний официальным сопроводительным письмом и предоставить Заказчику программу и методику испытаний (далее – ПМИ). Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком и Подрядчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытаний и Акт о приемке в опытную эксплуатацию, подтверждающий готовность П-МКП АСУ ТК к следующему виду испытаний – опытной эксплуатации Состав мероприятий, включенных в пилотную зону, может быть изменен по согласованию с заказчиком. В случае выявления ошибок в ПО П-МКП при проведении опытной эксплуатации, Подрядчик должен их устранить до начала приемочных испытаний. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки) Методы приемочных испытаний и порядок их проведения должны быть определены в документе «Программа и методика приемочных испытаний», который должен быть подготовлен Подрядчиком и утвержден Заказчиком до начала приемочных испытаний. По результатам проведения приемочных испытаний оформляются Протокол приемочных испытаний и Акт готовности П-МКП к эксплуатации. В Протоколе приемочных испытаний должны быть указаны перечень проверяемых сервисов, функций, возможностей, дата и время проведения приемочных испытаний, состав приемочной комиссии, рекомендации (при наличии) к решению, а также выводы о готовности П-МКП АСУ ТК к вводу в эксплуатацию. Ввод П-МКП АСУ ТК в эксплуатацию осуществляется после выполнения работ по ИБ, подписанием соответствующего акта 6.3 Порядок контроля и приемки выполненных работ Сдача-приемка выполненных работ осуществляется в соответствии с условиями Контракта. Сдача-приемка работ осуществляется по завершении каждого этапа в порядке, установленном в Контракте Значение характеристики не может изменяться участником закупки 6.3.1 Условия о порядке предоставления (передачи) результатов выполнения работ Заказчику Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ, а также в соответствии с инструкциями, приведенными в рабочей документации на П-МКП. Документация на П-МКП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика Значение характеристики не может изменяться участником закупки Передача исходных кодов, разработанных и/или передаваемых в ходе выполнения работ программ для электронных вычислительных машин (далее - программа для ЭВМ) и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных и/или передаваемых в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает заказчику исходные коды, дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения. 6.4 Сведения о гарантийном обслуживании Гарантийный срок: один год с даты подписания Заказчиком документа о приемке Этапа № 3. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, включая замечания и комментарии от федеральных органов исполнительной власти в области обеспечения безопасности, федерального органа исполнительной власти, уполномоченного в области противодействия техническим разведкам и технической защиты информации, Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерства транспорта Российской Федерации и Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций, выявленных после приемки выполненных Работ, в том числе в документации, разработанной по результатам выполненных Работ, касающиеся соответствия требованиям нормативных правовых актов, действующих на момент завершения этапа № 2. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, установленные Заказчиком в Акте с перечнем выявленных недостатков. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Гарантийным случаем признается полное или частичное отсутствие функционирования П-МКП и ее компонентов в результате выполнения работ по настоящему Техническому заданию. Подрядчик должен обеспечить гарантию работоспособности П-МКП, включая гарантийную поддержку Значение характеристики не может изменяться участником закупки В рамках гарантийной поддержки П-МКП Подрядчик должен: – устранять обнаруженные в процессе постоянной эксплуатации дефекты в работе П-МКП в срок не более 5-ти рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); – принимать участие в восстановлении работоспособности П-МКП после сбоев и аварий, вызванных дефектами и недокументированными возможностями подсистемы, выполняя при этом работы, связанные с восстановлением целостности данных и обновлением П-МКП; – вносить изменения в техническую и рабочую документацию на функциональные блоки, на основании выявленных неточностей или обнаруженных недокументированных возможностей подсистемы; – консультировать представителей Заказчика об особенностях реализации П-МКП, в том числе при установке, настройке и пуско-наладке Системы; – давать ответ на заявку Заказчика в течение 1 (Одного) рабочего дня с момента ее поступления 7 Источники разработки Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» Значение характеристики не может изменяться участником закупки Приложение А к Техническому заданию Таблица А.1 – Описание состава загружаемых данных по мероприятиям Раздел данных Подраздел данных Название атрибута Общая информация об объекте - Наименование Федерального проекта - Инвестпроект - Участок - Длина участка, км Провозная способность, млн. тонн в год план факт Пропускная способность, пар поездов в сутки план факт Максимальная весовая норма поездов, тонн план факт - Наименование мероприятия/объекта - Код объекта - Ответственный исполнитель/ заказчик (контакты) - Субъект Российской Федерации/фактическое (местоположение объекта) - Код ИП - Назначение объекта, основные характеристики объекта (ТЭП) - Предварительная стоимость по ФП (млн. руб.) Ход реализации (Проектирование) Заключен контракт на инженерные изыскания ПД план факт Направление ПД на ГГЭ план по условиям договора факт Получение заключения государственной экспертизы на ПСД план по условиям договора факт стоимость по итогам заключения ФАУ «Главгосэкспертиза России» - Сроки по ПОС Ход реализации (Строительство) Проведение конкурсных процедур на выполнение СМР Объявление торгов (план) Объявление торгов (факт) Заключение контракта на СМР (план) Заключение контракта на СМР (факт) Оформление земельно-правовых отношений* план факт выполнение в % Получено РС план факт Ввод объекта во временную эксплуатацию план факт Получен ЗОС план факт Ввод объекта в эксплуатацию (РВ) план по условиям договора* факт отклонение (дни) - Примечание Обеспеченность машинами и механизмами - план факт - - Строительная готовность (в %) Привлечение трудовых ресурсов, чел. - план факт - - Уровень риска реализации (определяется по наличию отставаний по контрольным точкам, влияющих на срок ввода в эксплуатацию) Объем финансирования в соответствии с ФП (млн. руб.) Год, по которому сформирован отчет Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Сводная бюджетная роспись на отчетную дату Значение характеристики не может изменяться участником закупки Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Термин Определение АРМ Автоматизированное рабочее место АСУ ТК Информационно-аналитическая система регулирования на транспорте БД База данных ВПЦТ Ведомственная программа цифровой трансформации ГИС Геоинформационная система ГОСТ Государственный стандарт ГПЗУ Градостроительный план земельного участка ГПР График производства работ ДПТ Документация по планировке территории ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации ИРД Исходно-разрешительная документация ИС Информационная система КИИ Критическая информационная инфраструктура КПМИ Комплексный план модернизации и расширения магистральной инфраструктуры КПЭ Ключевые показатели эффективности КСГ Календарно-сетевой график КТ Контрольная точка КЭП Квалифицированная электронная подпись ОЖР Общий журнал работ ОС Операционная система ОТИ Объект транспортной инфраструктуры ПИР Проектно-изыскательные работы П-МКП Подсистема «Мониторинга комплексного плана» ПНР Пусконаладочные работы ПО Программное обеспечение РФ Российская Федерация СЗИ Система защиты информации СМР Строительно-монтажные работы СМЭВ Система межведомственного электронного взаимодействия СПО Специализированное программное обеспечение ССР Сводный сметный расчет СУБД Система управления базами данных СЭД Система электронного документооборота ТЗ Техническое задание ТЭО Технико-экономическое обоснование ТЭП Технико-экономические показатели ФБГУ Федеральное государственное бюджетное учреждение ФЗ Функциональная задача ФИО Фамилия, имя, отчество ФНС России Федеральная налоговая служба ФП Федеральный проект - - Значение характеристики не может изменяться участником закупки - ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик») - 1 Общие сведения 1.1 Наименование системы - Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. - - Значение характеристики не может изменяться участником закупки - 1.2 Наименование Заказчика и Подрядчика - Заказчик: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации». Оператор Системы: Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», согласно распоряжениям ТУ Росимущества в городе Москве № 77-594-р от 30.04.2021 и № 77-566-р от 25.05.2022 информационно-аналитическая система регулирования на транспорте (АСУ ТК) находится на праве оперативного управления ФГБУ «СИЦ Минтранса России», исключительное право зарегистрировано Федеральной службой по интеллектуальной собственности Российской Федерации. Подрядчик определяется по результатам проведения закупочной процедуры - - Значение характеристики не может изменяться участником закупки - 1.3 Основания для выполнения работ - 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; - - Значение характеристики не может изменяться участником закупки - 10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010; - 17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - 1.4 Перечень документов, требования которых должны быть учтены при выполнении работ - 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - - Значение характеристики не может изменяться участником закупки - 11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»; - 25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации - 1.5 Сроки начала и окончания работ - Начало работ: с даты заключения Контракта. Окончание работ: не позднее 30.06.2026. Работы выполняются в соответствии с этапами. Сроки выполнения работ по каждому этапу определяются графиком выполнения работ (календарным планом) в соответствии с пунктом 5.1 настоящего ТЗ (далее – Календарный план) - - Значение характеристики не может изменяться участником закупки - 1.6 Порядок оформления и предъявления результатов работ - Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5.1 настоящего ТЗ, в соответствии с Календарным планом и Контрактом - - Значение характеристики не может изменяться участником закупки - 1.7 Место выполнения Работ - Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет. Тестовый стенд для проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний предоставляет Заказчик. Доступ к тестовому стенду Заказчик предоставляет Подрядчику на основании письменного обращения. Требования к предоставляемым вычислительным мощностям должны соответствовать требованиям, указанным в пояснительной записке, представляемой на этапе № 1 работ - - Значение характеристики не может изменяться участником закупки - 2 Назначение и цели развития Системы 2.1 Назначение Системы - Основными задачами, решаемыми в настоящий момент системой АСУ ТК, являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов контроля безопасности и устойчивости транспортного комплекса, управления в чрезвычайных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими органами государственной власти, а также гражданами и организациями - - Значение характеристики не может изменяться участником закупки - АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными стратегическими целями развития АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и принятия мер по их устранению и ликвидации последствий - 2.2 Цели развития Системы - Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - Основными целями выполнения работ являются: – создание среды взаимодействия участников строительства на этапах реализации процесса строительства (реконструкции); – создание единого источника достоверной, непротиворечивой и верифицированной информации для принятия решений на всех управленческих уровнях; – повышение достоверности и прозрачности информации об инвестиционных проектах и программах; – повышение дисциплины формирования и предоставления плановых и отчетных форм; – обеспечение единого информационного пространства инструментам регистрации, хранения, согласования документов-обоснований; – обеспечение инструментов контроля полной стоимости, статей затрат по базовым, текущим ценам и ценам инвестиционного проекта, и физическим характеристикам; – обеспечение формирования графиков, контроля исполнения и сигнализация рисков неисполнения контрольных этапов; – повышение прозрачности процессов и оптимизация взаимодействия между различными участниками реализации инвестиционных проектов. Достижение указанных целей осуществляется для достижения стратегических целей развития АСУ ТК, указанных в пункте 2.1 ТЗ. Основные процессы, автоматизируемые в рамках выполнения Работ: – управление инвестиционными проектами строительства и реконструкции; – управление разработкой и согласование ПИР на всех стадиях реализации проекта; – управление задачами участников проектов строительства и реконструкции; – формирование и согласование исполнительной документации; – формирование и ведение календарно-сетевого планирования; – проведение процедуры строительного контроля; – формирование отчетности - 2.3 Состав выполняемых задач - Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей - 3 Сведения об объектах автоматизации 3.1 Описание объектов автоматизации - Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими органами государственной власти, гражданами и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. В соответствии с Аттестатом соответствия требованиям по защите информации АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с постановлением Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» - - Значение характеристики не может изменяться участником закупки - 3.2 Текущее состояние объекта автоматизации - Текущая архитектура АСУ ТК приведена на рисунке 1. Рисунок 1 – Архитектурная схема АСУ ТК АСУ ТК осуществляет идентификацию и авторизацию посредством ЕСИА. Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3, СМЭВ 4, а также с использованием технологий API и FTP с учетом требований Технических условий на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России», утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД. АСУ ТК развернута на вычислительных мощностях Головного центра обработки данных ФБГУ «СИЦ Минтранса России». На этапе технического проектирования Подрядчик формирует требования к необходимым вычислительным мощностям для разворачивания ПО, создаваемого в рамках настоящего ТЗ. В текущей конфигурации Подсистема «Мониторинга комплексного плана» (П-МКП) обеспечивает выполнение следующих основных функций: – обеспечение оперативного взаимодействия участников реализации КПМИ в цифровой форме при подготовке, изменении и реализации планов-графиков ФП КПМИ; – визуализация содержащихся в П-МКП данных, представление их в удобном для анализа виде; – ранжирование объектов планов-графиков ФП КПМИ, в соответствии с Методикой ранжирования отдельных мероприятий, включаемых в ФП КПМИ на период до 2024 года ; – мониторинг исполнения планов-графиков ФП КПМИ, включая сбор, обработку, представление данных, необходимых для мониторинга и формирования отчетов на основе данных мониторинга планов-графиков в соответствии с Методическими указаниями по мониторингу и внесению изменений в Комплексный план модернизации и расширения магистральной инфраструктуры на период до 2024 года (транспортная часть) и ФП КПМИ - - Значение характеристики не может изменяться участником закупки - АСУ ТК состоит из платформенных решений и функциональных задач, разделенных на логические подсистемы. Функциональные задачи, в свою очередь, состоят из наборов АРМ, предоставляющих различные функциональные возможности. Матрицы платформенных решений и функциональных задач АСУ ТК представлены в таблице 1. Таблица 1 – Перечень подсистем, модулей и функциональных задач АСУ ТК № п/п Наименование подсистемы/модуля/функциональной задачи Краткое наименование подсистемы/модуля/функциональной задачи - 1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП - 3.2.1. Состав используемого ПО - Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. - - Значение характеристики не может изменяться участником закупки - Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ - Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ) - 3.3 Объект автоматизации в рамках настоящего Технического задания - Предметом автоматизации является объединение в едином информационном пространстве данных по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, в отношении которых предусмотрена реализация мероприятий по строительству (реконструкции) в рамках национальных и федеральных проектов. Объекты автоматизации перечислены далее - - Значение характеристики не может изменяться участником закупки - 3.3.1. Физические объекты - Объекты транспортной инфраструктуры, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – автомобильные дороги федерального, регионального, межмуниципального и местного значения; – железнодорожные пути и станции, сопутствующая инфраструктура; – аэродромы и аэропортовые комплексы; – морские и речные порты, причалы, судоходные гидротехнические сооружения. Иные объекты, относящиеся к ведению Минтранса России, находящиеся на стадиях проектирования, строительства и реконструкции, включая: – суда, в том числе аварийно-спасательный и вспомогательный флот; – пункты пропуска через государственную границу Российской Федерации - - Значение характеристики не может изменяться участником закупки - 3.3.2. Информационные объекты - Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) - - Значение характеристики не может изменяться участником закупки - 3.3.3. Процессы автоматизации - Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных - - Значение характеристики не может изменяться участником закупки - 3.3.4. Взаимодействие участников - Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах - - Значение характеристики не может изменяться участником закупки - 4 Требования к Работам - Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы - - Значение характеристики не может изменяться участником закупки - 4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре - 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 - - Значение характеристики не может изменяться участником закупки - 17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17 - Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком. - В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей - Уровень хранения данных: – распределенные базы данных; – предзаполненный набор справочников, содержащих нормативно-справочную информацию; – отдельно вынесенный базовый функционал, обеспечивающий сохранение и обработку данных. Уровень информационного взаимодействия: – выполнение автоматизированных операций, обеспечивающих подготовку (агрегирование данных) и передачу данных между контурами. Уровень файлового хранения: – распределенная файловая система, обеспечивающая хранение и обработку загруженных в систему файлов. Уровень работы микро- и макросервисов: – запускаемые в асинхронном режиме application instance, нацеленные на выполнение отдельных ресурсоемких задач и использующие минимальный набор внутренних зависимостей, необходимых для выполнения задачи. При проектировании и разработке всех составляющих компонентов следует использовать единую методологию и единые принципы взаимодействия, надежности и управления - 4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков - № Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4 - 4.1.2 Требования к режимам функционирования П-МКП по результатам Работ - П-МКП должна предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования должен быть штатный. В штатном режиме все подсистемы корректно и полностью должны выполнять свои функции. Перерывов в работе как П-МКП в целом, так и одного, либо нескольких компонентов, не предусмотрено. Режим регламентного (профилактического) обслуживания должен быть предназначен для проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе П-МКП с приемочным информированием пользователей. Состав процедур по регламентному обслуживанию П-МКП и их периодичность должны быть определены Подрядчиком в процессе выполнения работ по созданию П-МКП. В режиме регламентного (профилактического) обслуживания П-МКП может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов П-МКП, а также резервному копированию данных с условием предварительного оповещения пользователей. Конечный состав процедур, требующих перевода П-МКП в данный режим, должен быть определен Подрядчиком - - Значение характеристики не может изменяться участником закупки - Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ - 4.1.3 Показатели назначения - В рамках выполнения работ по развитию Системы, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в таблице 3. Таблица 3 – Определения показателей, связанных с количеством пользователей в подсистеме «Мониторинга комплексного плана» (П-МКП) № Показатель Определение 1 Расчетное количество пользователей Количество пользователей, работу которых должна обеспечить Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения 2 Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должна обеспечивать Система к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения - - Значение характеристики не может изменяться участником закупки - Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в таблице 4. Таблица 4 – Значения показателей количества пользователей подсистемы «Мониторинга комплексного плана» (П-МКП) № Показатель Значение 1 Расчетное количество пользователей 1000 2 Расчетное среднее количество одновременно работающих пользователей 500 Развитие Системы должно быть направлено на достижение следующих описаний ключевых результатов (ОКР), в рамках ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» мероприятия 1 ВПЦТ Минтранса России на период 2026-2028: · «Реализован функционал цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры подсистемы «Мониторинга комплексного плана» АСУ ТК». · «Проведено импортозамещение подсистемы «Мониторинга комплексного плана» АСУ ТК» - 4.1.4 Требования к надежности функционирования и доступности для пользователей - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надежность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счет: – обеспечения требуемого уровня квалификации обслуживающего персонала; – регламентации и нормативного обеспечения выполнения работ обслуживающего персонала; – своевременной диагностики неисправностей. Расчетное значение коэффициента готовности АСУ ТК должно составлять не менее 0,95. Планы и процессы обеспечения непрерывности функционирования АСУ ТК должны быть увязаны с перечнем наиболее критических компонентов АСУ ТК, перечнем наиболее важных информационных ресурсов АСУ ТК - - Значение характеристики не может изменяться участником закупки - ПО АСУ ТК должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов АСУ ТК; – сохранение работоспособности ПО при некорректных действиях пользователя; – резервное копирование БД Системы. Средства АСУ ТК по итогам развития должны обеспечивать следующие характеристики надежности при определенном уровне доступности функций: – операционное время: 24x7; – время восстановления работоспособности Системы после отказа или проведения регламентных работы: не более 4 часов; – отказоустойчивость на уровне 99% при единовременном обращении к Системе не менее 10 пользовательских сессий. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи публичных сетей. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Система должна автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом или исполняемых программных кодов Системы либо ее компонент) - 4.1.5 Требования по диагностированию Системы - Компоненты АСУ ТК должны предоставлять инструменты автоматического диагностирования основных процессов Системы, а также работоспособности специального и общего ПО. АСУ ТК должна предоставлять возможность просмотра диагностических событий и действий, выполняемых пользователями Системы. Диагностирование должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего ПО Системы. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Системы; – сбои и нарушения функционирования системного ПО серверов Системы; – сбои и нарушения функционирования прикладного ПО серверов Системы; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в ПО диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы - - Значение характеристики не может изменяться участником закупки - 4.1.6 Требования к транспортабельности - Не предъявляются - - Значение характеристики не может изменяться участником закупки - 4.1.7 Требования к эксплуатации и техническому обслуживанию - Обслуживание Системы должно производиться обслуживающим персоналом. Допускается использование специализированных служб или подразделений на объектах внедрения для обслуживания и ремонта оборудования. При эксплуатации Системы должны использоваться штатные методы защиты от механических, тепловых, электромагнитных и других воздействий, защиты данных, в том числе, от несанкционированного доступа к ним, применяемые у Заказчика. Должно быть предусмотрено ежедневное/еженедельное техническое обслуживание Системы. При возникновении неисправностей должно осуществляться оперативное обслуживание - - Значение характеристики не может изменяться участником закупки - 4.1.8 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды - Специальных требований к условиям эксплуатации объекта автоматизации и характеристиках окружающей среды не предъявляется - - Значение характеристики не может изменяться участником закупки - 4.1.9 Требования к информационной безопасности - Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего : – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; - - Значение характеристики не может изменяться участником закупки - – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 17, 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 20, 20.14, 25(1) и 25(2) Требований, о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11.02.2013 № 17; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.1.10 Требования к безопасности исходного кода - Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО - - Значение характеристики не может изменяться участником закупки - Заказчик предоставляет результаты контрольных проверок, зафиксированных в артефактах сборочного процесса, Подрядчику для устранения в срок до даты завершения исполнения Контракта. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. Подрядчик обязуется разработать меры предотвращения угроз безопасности, в том числе рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности и т.д., в случае, если уязвимость не подлежит исправлению на программном уровне. Подрядчик обязуется заменить/обновить библиотеки в случае обнаружения уязвимого компонента - 4.1.11 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов - Требования к эксплуатации оборудования Заказчик обеспечивает самостоятельно или с помощью привлеченных сторонних организаций. Для нормальной эксплуатации разрабатываемого ПО должно быть обеспечено бесперебойное питание серверов. При эксплуатации должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации серверов температура и влажность воздуха. - - Значение характеристики не может изменяться участником закупки - 4.1.12 Требования по сохранности информации при авариях - При аварийных ситуациях в АСУ ТК должна обеспечиваться сохранность информации. Реализуемые технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т. п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - - Значение характеристики не может изменяться участником закупки - 4.1.13 Требования к патентной чистоте и патентоспособности - 4.1.13.6. В случае, если при выполнении Работ используется готовое ПО (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права (в установленном Гражданским кодексом Российской Федерации порядке) или неисключительные права (путем заключения лицензионного/сублицензионного договора по форме, установленной Контрактом) на такое ПО со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия – Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое ПО; – должны передаваться исходный код, дистрибутивы, эксплуатационная и техническая документация. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные ТЗ для соответствующего функционала системы . Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо дополнительные обязанности (в т.ч. в части конфиденциальности, предоставления отчетности, предоставления правообладателям доступа к ПО и т.п.), не предусмотренные Контрактом - - Значение характеристики не может изменяться участником закупки - 4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1.13.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, БД, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами документа о приемке по соответствующему этапу исполнения контракта. Разработанное ПО поставляется вместе с исходными кодами. - 4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности - 4.1.13.3. Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок ПО (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с ТЗ. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.1.13.4. Подрядчик должен подтвердить, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела ТЗ. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части и иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними - 4.1.13.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам - 4.1.13.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта - 4.1.14 Требования к численности персонала оператора Системы - Дополнительные требования к численности персонала оператора не предъявляются - - Значение характеристики не может изменяться участником закупки - 4.1.15 Требования к квалификации персонала Системы, порядку его подготовки и контроля знаний и навыков - Специальные квалификационные требования предъявляются к системным администраторам. Помимо наличия базовых навыков работы на персональном компьютере, к системным администраторам предъявляются следующие требования: – знание основных принципов построения СУБД; – наличие расширенных знаний в области поддержки пользователей; – знание основ администрирования ОС семейства Linux, а также серверов приложений и серверов БД, функционирующих под управлением указанных ОС. Уровень квалификации системных администраторов должен соответствовать требованиям исполнителей (производителей) ПО и технических средств Системы, а также требованиям эксплуатационной документации - - Значение характеристики не может изменяться участником закупки - 4.1.16 Требуемый режим работы персонала оператора Системы - Режим работы персонала должен соответствовать действующему законодательству Российской Федерации (РФ) и обеспечивать работоспособность Системы согласно требованиям, предъявленным настоящим ТЗ. Должна быть учтена возможность сменного режима работы персонала Системы. При этом должна учитываться возможность круглосуточного подключения к работам специалистов, обеспечивающих функционирование Системы (администраторов и специалистов по техническому обслуживанию), для решения проблем по обеспечению работоспособности информационных ресурсов Системы - - Значение характеристики не может изменяться участником закупки - 4.1.17 Требования к эргономике и технической эстетике - Взаимодействие пользователей с Системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме, возможно, системных сообщений), должны быть на русском языке. Все экранные формы должны иметь текстовую справку, в которой должна быть описана инструкция по работе с данной экранной формой. На всех экранных формах при выполнении операций должна быть выведена индикация, которая информирует пользователя о статусе выполнения операции. Система должна обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введеенных значениях - - Значение характеристики не может изменяться участником закупки - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя манипулятора типа «мышь», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов. Структура размещения информации и представление этой структуры в Системе должны соответствовать следующим требованиям: – пункты меню в пользовательских веб-интерфейсах должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – пункты меню должны называться или изображаться так, чтобы пользователь однозначно понимал их назначение; – при совершении пользователями ошибочных действий должны выдаваться сообщения на русском языке, на основе которых пользователь может определить причину ошибки и способы ее устранения. Интерфейс АСУ ТК должен быть понятен для пользователя на всех стадиях ввода, обработки, анализа и передачи информации, должен позволять пользователю свободно ориентироваться в общем информационном и функциональном пространстве АСУ ТК. Визуальное представление элементов пользовательского интерфейса АСУ ТК и состав отображаемой информации подлежат согласованию Заказчиком в процессе выполнения работ по модернизации Системы - 4.2 Требования к содержанию работ 4.2.1 Архитектурное решение - 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки - 4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком - 4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур. - 4.2.2 Требования к масштабируемости и расчету мощностей - 4.2.2.1 Модульность и горизонтальное масштабирование Архитектура ПО должна быть модульной и поддерживать горизонтальное масштабирование (scale-out) контуров без изменения исходного кода приложения. Функциональный контур масштабируется путем создания копий и подключения к сервису передачи агрегированных данных в информационно-аналитический контур. При этом могут применяться стратегии административного, функционального или географического разделения пользователей по экземплярам контура, в том числе с помощью настройки конфигурации приложения каждого экземпляра. Критичные компоненты, такие как серверы приложений, веб-сервисы и обработчики очередей, должны быть спроектированы как независимые, stateless (бессостоятельные, не сохраняющие состояние на самом сервере) сервисы. Хранение состояний приложения возможно с использованием СУБД. Это позволит увеличивать производительность и отказоустойчивость за счет добавления новых экземпляров сервисов в пул под нагрузкой балансировщика - - Значение характеристики не может изменяться участником закупки - 4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ - 4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов - 4.2.3 Требования к функциональным блокам информационно-аналитического контура - Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». - - Значение характеристики не может изменяться участником закупки - Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов. Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам и по годам с разделением по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Освоено» должен отображать освоение (принято) в млн. руб. с разделением по годам, с фильтрацией по признакам: – всего нарастающим итогом с начала реализации (до утв. паспорта ФП); – всего нарастающим итогом после утверждения паспорта ФП; – всего с начала отчетного года; – всего с начала отчетного месяца; – всего по контракту/контрактам. Виджет «Контрактация» должен отображать плановый объем финансирования по контракту/ контрактам в отношении к «Законтрактовано в млн. руб» с нарастающим итогом с начала отчетного года. Необходимо реализовать фильтрацию по: – федеральному бюджету; – бюджету субъекта; – ФНБ; – внебюджетному финансированию (ОАО «РЖД» и т.п.). Виджет «Контрактация по контрактам» должен отображать сводную информацию о видах и количестве контрактов, которые были заведены. Виджет «Обеспеченность машинами и механизмами» должен отображать наличие машин и механизмов по плановому и фактическому значению в разрезе объектов. Виджет «Динамика по трудовым ресурсам (чел.), машинам и механизмам (в ед.)» должен отображать привлечение трудовых ресурсов по плану-факту с возможностью фильтрации по периоду. Виджет «Строительная готовность объекта» должен отображать готовность объекта в процентах. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Паспорт объекта должен содержать следующие вкладки: – «Паспорт» (информация и параметры объекта, участники строительства, сведения о затратах с фильтрацией по бюджетам, проблемные вопросы); – «Показатели» с возможностью редактирования; – «Финансирование» (сведения о выделенных и доведенных д\с в разбивке по бюджетам); – «Контракты» (сведения о заключенных контрактах по объекту с возможностью редактирования); – «Строительный контроль» (количество выявленных недостатков по типам; – «Подробные сведения о выявленных недостатках» с возможностью редактирования; – «Проблемные вопросы» (сведения о проблемных вопросах в разбивке по типам); – «Задачи» (доступ к функциональному блоку по работе с задачами с возможностью создания новых задач); – «Фотогалерея» (изображения с площадки строительства объекта). Необходимо реализовать виджеты, отображающие аналитическую информацию о количестве контрольных точек (далее - КТ), отражающих ход реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, относящихся к ведению Минтранса России. Все виджеты данной группы должны иметь следующие фильтры по: – национальным и федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – статусу достижения; – видам работ (проектирование, получения заключения государственной экспертизы проектной документации, строительно-монтажные работы, ввод в эксплуатацию и др.) - Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов должна раскрываться таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ. Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и их срок . Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о соблюдении ранее установленного срока, выполненных ранее срока, выполненных в срок, не выполненных в срок (срок истек), не выполненных (срок не наступил). Виджет «Контрольные точки, риски» должен отображать общее количество объектов, количество завершенных объектов, количество объектов с высокой степенью риска, со средней и умеренной/ отсутствующей. При нажатии на количество объектов должна открываться таблица с объектами и контрольными точками, отображающими текущую КТ, план и факт по каждой контрольной точке с подсвечиванием отставания соответствующим цветом. Зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев; Необходимо реализовать виджет, который отображает аналитическую информацию о текущих и прогнозных рисках и их влиянии на показатели национальных и федеральных проектов с возможностью выбора параметра (мощности), влияние на который оказывают объекты, и добавления фильтров по: – федеральным проектам; – субъектам Российской Федерации и федеральным округам; – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств - 4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.3.4 Функциональный блок загрузки данных Функциональный блок предназначен для обеспечения информационного обмена со смежным контуром и должен обеспечивать получение (загрузку) актуальных данных по проектам, объектам, их финансированию и контрольным точкам исполнения. Данные должны сохранятся в функциональном блоке в агрегированном (сводном) виде и использоваться в качестве источника информация для построения виджетов аналитической панели, а также отчетов. Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных; – преобразования данных; – сохранения данных; – хранения истории запусков. Должны быть реализованы следующие стратегии загрузки: – ручная загрузка данных, предоставленных в файлах; – автоматическая загрузка данных из смежного контура. Автоматический режим подразумевает под собой фоновую регулярную загрузку сводной информации, собранной на основе актуальных данных, вводимых в функциональные блоки Ручной режим загрузки должен обеспечивать возможность загрузки данных по шаблону. Файл для загрузки должен быть в формате *xlsx. Данные могут предоставляться как в полном объеме шаблона, так и в частичном. Функция преобразования данных из файла формата xlsx должна использовать следующие стратегии: – валидация данных на соответствие шаблону; – применение функций преобразования к отдельным полям источника данных, такие как приведение типов, преобразование формата даты; – агрегация данных по выбираемым категориям; – применение функций преобразования для получения вычисляемых значений; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования - Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция хранения истории запусков должна фиксировать следующую информацию: – дата и время загрузки; – название источника; – статус загрузки; – сообщение об ошибках (при наличии). При помощи шаблона предполагается загрузка следующей сводной информации по объектам строительства: – наименование объекта строительства, федерального проекта, инвестиционного проекта, указание местоположения и пр. основные характеристики; – общая информация об объекте, включающая в себя плановые и фактические показатели с детализацией по годам за 5 лет; – плановые и фактические показатели хода реализации, описывающие сроки достижения контрольных точек этапов проектирования и строительства; – плановые финансовые показатели с детализацией по годам и источникам финансирования, включающие в себя объем финансирования и план освоения; – плановые и фактические показатели по контрактации; – плановые и фактические показатели по обеспеченности машинами и механизмами; – плановые и фактические показатели по привлечению трудовых ресурсов; – информация о строительной готовности; – информация об уровне риска реализации и необходимым мерам. Данные, переданные в функциональный блок посредством ручной загрузки отчета, должны сохраняться как в сводном виде, подходящем для показа в аналитических панелях, так и фиксироваться в виде пакета (отчета) с сохранением времени загрузки и автора - В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.3.1 АРМ Сотрудника Функциональный блок должен обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников: – сводной информации, полученной из функционального контура; – информации, сформированной в иных системах (программных продуктах) и загруженной с помощью импорта файла формата xlsx установленной структуры. Информация, собираемая и показываемая в АРМ Сотрудника, должна иметь возможность быть представленной как в рамках конкретного объекта, так и в рамках группы объектов, заданной набором фильтров. В состав данной информации должны входить показатели исполнения объекта, финансовые показатели, фиксация прохождения контрольных точек реализации исполнения. Для показа информационной сводной панели необходимо разработать функциональный блок настраиваемых аналитических панелей - компонент графического представления данных для отображения набора настраиваемых виджетов с возможностью создания (настройки) панелей для анализа информации по различным бизнес-процессам. Для формирования и выгрузки аналитических данных в форме табличного отчета необходимо разработать функциональный блок отчетности. Данный компонент должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов и достижении ключевых событий. Для сбора информации, необходимой для формирования аналитических панелей и отчетов, требуется разработать функциональный блок загрузки данных. Компонент должен обеспечивать регулярную автоматическую загрузку данных из контура функционального уровня в сводном агрегированном виде, достаточном для показа на панелях и для формирования отчетов. Кроме того, в компоненте должна быть предусмотрена возможность ручной загрузки данных в подготовленном формате - 4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта) - Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер должен представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также требуется реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры; – годам; – заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания; – переход в информационный паспорт объекта во вкладке таблицы. - 4.2.4 Функциональные требования к блокам функционального контура - 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. - - Значение характеристики не может изменяться участником закупки - Функциональный блок должен предусматривать возможность выполнения следующих функций: – импорта данных из файлов формата xml; – преобразования данных; – сохранения данных; – фиксация выполненных действий по созданию/изменению в истории событий. Функция преобразования данных из файла формата xml должна использовать следующие стратегии: – валидация файла на соответствие xsd-схемам, утвержденным Минстроем России и опубликованным на официальном сайте как актуальные; – валидация данных файла на соответствие форматам ожидаемых данных и данным, уже имеющимся в П-МКП, в т.ч. проверка наличия и доступности пользователю объекта строительства, юридических лиц, указанных в документе. Полный набор критериев валидации должен быть разработан на этапе № 1 Календарного плана; – применение функций преобразования к отдельным полям источника данных, таким как приведение типов, преобразование формата даты; – соотнесение отдельных видов данных с данными, сохраненными в связанных справочниках контура (в т.ч. определение проекта и объекта, его местоположения); – уведомление пользователей о выявленных нарушения преобразования. Функция сохранения данных должна использовать следующие стратегии: – выбор целевой таблицы для загрузки данных; – настройка соответствия полей при загрузке данных в целевую таблицу; – проверка данных целевой таблицы для повторного использования; – использование сохраненных данных для визуализации данных. Функция сохранения истории событий должна фиксировать в т.ч. следующую информацию: – дату и время события; – название события; – автора события; – сохраняемые или изменяемые данные - Данные, полученные на основании загруженного файла, должны сохраняться в качестве документов или записей, соответствующих данному документу, с фиксацией всей информации, содержащейся в файле (в т.ч. объект строительства, юридические и физические лица, информация об объемах, суммах и пр). Файл формата xml, на основании которого создан документ или запись, должен быть прикреплен к карточке этой записи и доступен для скачивания. Документы и записи, созданные посредством загрузки данных из файлов xml, должны быть доступны загрузившему их пользователю в соответствующей вкладке АРМ Подрядчика, а также сотрудникам Заказчика, имеющим доступ к объекту строительства. Функциональный блок должен поддерживать возможность загрузки файлов с измененными данными по документу (новые версии документа) с возможностью связать созданный документ с его предыдущими версиями или обновить (заменить) данные в уже существующем документе без создания новой версии. Во втором случае файл, содержащий данные об изменениях, должен быть прикреплен в качестве новой версии исходного файла. В функциональном блоке должна быть возможность разграничения прав на загрузку отдельных видов документов, определяемая настройкой прав пользователей и ролевой моделью. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов - В рамках функционального блока требуется разработать следующий набор вкладок: – список доступных Подрядчику объектов с возможностью фильтрации по общей информации об объекте (тип, вид статус, адрес объекта, участники реализации и др.) и просмотра краткой информации по каждому из них. Общий перечень данных в карточке не должен превышать описанный в разделе функциональный блок «Информация»; – вкладки с реестрами загруженных документов с возможностью группировки по типам и объектам, с возможностью перехода к карточке документа; – карточки отдельных документов, содержащие в себе основную информацию о документе и его участниках, версию документа, прикрепленный файл в формате xml, на основании которого документ был создан, список замечаний, выданных по документу, возможность выполнения действий по согласованию и подписанию с использованием функционального блока для ведения электронного документооборота (СЭД); – вкладка загрузки данных из файлов формата XML по схемам, определенным Минстроем России для передачи документов в электронном виде и опубликованным на официальном сайте; – список пользователей, являющихся представителями Подрядчика и имеющих доступ к АРМ Подрядчика и конкретным объектам в нем, с возможностью управления доступом, подключением новых пользователей и блокировкой ранее подключенных. Необходимо предусмотреть возможность для администратора от Подрядчика управлять доступом отдельных пользователей к конкретным объектам строительства; – список аккаунтов для взаимодействия с внешней системой электронного документооборота, в случае использования Удостоверяющего центра для подписания документов с использованием КЭП (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). - Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); - 4.2.4.4.3. Требования к созданию виджетов Необходимо разработать следующий функционал: – реализовать возможность точечной настройки аналитических виджетов по дате формирования данных (при необходимости); – выполнить возможность непосредственного перехода от информации на виджете дашборда к источникам данных; – реализовать возможность пользовательской настройки отображения и группировки виджетов - 4.2.4.2 АРМ Заказчика Функциональный блок АРМ Заказчика должен включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны Заказчика доступом к АРМ Подрядчика для сотрудников Подрядчиков. Функционал должен обеспечивать следующие возможности: – просмотр списка новых объектов строительства; – возможность перехода к карточке объекта, возможность добавления новых объектов; – просмотр списка юридических лиц, выступающих Подрядчиками на проектах, возможность просмотра информации о них, добавления новых, редактирования и удаления созданных ранее; – возможность создания АРМ Подрядчика для юридических лиц, выполняющих работы на объекте; – просмотр списка пользователей, являющихся представителями подрядчика, управление их доступом к АРМ Подрядчика, возможность добавления новых и блокировки неактуальных (уволенных, прекративших свою деятельность по проекту). Функциональный блок должен разрабатываться в интерфейсах, аналогичных АРМ Подрядчика. Информация представляется в виде вкладок, осуществляющих: – работу с объектами строительства; – работу и управление Подрядчиками; – настройку АРМ Подрядчика; – управление пользователями АРМ Подрядчика; – просмотр и работу с предоставленными документами через механизм загрузки в формате XML. Объем данных, выводимых в каждой вкладке, регулируется правами доступа пользователя-администратора Заказчика к объектам и юридическим лицам. Доступ к АРМ Заказчика в целом и к конкретным вкладкам в нем, должен управляться настройкой прав пользователя. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных - К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - – возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки) - 4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией - 4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); - 4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9.2. Требования формированию плана освоения. Раздел функционального блока «ГПР» - вкладка «План освоения» Необходимо иметь возможность учитывать все виды ресурсов: материалы, машины и механизмы, рабочую силу, а также планировать их потребление. Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» представлены в таблице 7. Таблица 7 – Требования к вкладкам раздела функционального блока «ГПР» - вкладка «План освоения» № п/п Функциональность вкладок 1 Должен формироваться план освоения в объемах и деньгах на основании графика работ с возможностью детализации по настраиваемым периодам распределения, настраиваемым типом расчета. В рамках плана освоения должна отображаться информация по плановым, фактическим показателям, показателям по директивному плану и закрывающим документам, а также показатели по отклонениям (план-факт, план-закрыто, факт-закрыто). 2 Должен отображаться ресурс типа -материалы. 3 Должен отображаться ресурс типа -машины и механизмы. 4 Должен отображаться ресурс типа -рабочая сила и кадры. 5 Должен позволять формировать накопительную ведомость - Также необходимо настроить систему уведомлений на почту ___@___ в системе. В уведомлении указываются сведения: 1) об объекте капитального строительства с указанием адреса (местоположения) объекта и времени проведения контрольных мероприятий; 2) о предъявляемых к освидетельствованию видов (этапов) работ, конструкций с указанием осей, пикетов, рядов, отметок или иных привязок мест расположения объекта освидетельствования и об участниках строительства, привлекаемых для выполнения указанных работ; – формирование аналитической информации по недостаткам; – отображение типовых нарушений со ссылкой на нормативные правовые акты; – замещение инспектора строительного контроля; – добавление недостатков, которые устранены в ходе проверки; – привязка недостатков к элементам BIM моделей; – привязка проверок к ПД/РД/ИД; – привязка недостатков к элементам графика производства работ; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.4.2. Требования к отображению объекта на интерактивной схеме Функционал должен включать отображение объектов на интерактивной схеме РФ, расположенной на аналитической панели – дашборд. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта). Требования к разрабатываемому функционалу: – возможность фильтрации объектов на интерактивной схеме, карте и таблице при выделении субъекта РФ на схеме; – возможность масштабирования картографической карты; – отображение на карте маркеров всех объектов. Маркер представляет собой графическое отображение параметра «объекта» в виде иконки. При наведении на маркер должна отображаться краткая информация об объекте: наименование объекта, адрес; – фильтрация количества объектов с помощью общей фильтрации дашборда по следующим признакам: наименование объекта, проект, статус объектов, тип объекта. Также необходимо реализовать фильтрацию по: – субъектам РФ и федеральным округам; – национальным и федеральным проектам (виджет должен отображать количество объектов относящихся к национальным и/или федеральным проектам); – видам транспорта и инфраструктуры); – годам; – Заказчикам; – главным распорядителям бюджетных средств; – источникам финансирования; – наличию риска реализации; – плановой дате начала и дате окончания. Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.14 Функциональный блок ведения договоров «Управление проектом» Необходимо разработать следующий функционал: – формирование категорий контрактов; – формирование контрактов с указанием статусов, основных показателей и условий, предусмотренных контрактом (обязательства, авансы, дополнительные соглашения, гарантийные удержания и др.); – формирование и учет платежей по контрактам с привязкой к типу, план/факт, не законтрактовано (год) и типу бюджета; – формирование дополнительных соглашений к контракту с автоматическим изменением суммы, плановой даты начало/окончания контракта; – аналитика контрактов по текущим статусам, видам и типам выполняемых работ на объекте. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.8 Функциональный блок «Информация» Данный функциональный блок содержит требования к функциям ведения карточек проектов и программ. В рамках выполнения Работ необходимо организовать ввод, обмен и хранение, и актуализацию данных по проектам и программам. Карточка объекта/программы должна содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и Подрядчиков по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков). Виды информации: – общая информация об объекте строительства (тип, вид статус, адрес объекта, участники реализации и др.); – данные по освоению денежных средств (кассовое исполнение, оплачено по контрактам, риск неосвоения лимитов); – отображение всех показателей объекта (технико-экономические показатели, статус реализации, градостроительная проработка и др.); – информация по финансированию объекта (выделение и доведение денежных средств); – информация по контрактам объекта; – информация по вопросам, возникающим в ходе реализации; – данные по выполнению задач по объекту; – фотогалерея; – видеонаблюдение в режиме реального времени. При открытии карточки объекта должен открываться функциональный блок «Информация», в котором указывается сводная информация по объекту, разделенная по вкладкам согласно таблице 5 - – Виджет «Текущая аналитика СМР по ГПР» должен отображать данные по выполненным работам и освоенным средствам. Учитываются только данные из актуальных ГПР стадии СМР; – Виджет «Мониторинг исполнения ГПР, СМР» должен отображать сводную информацию о сроках исполнения плановых графиков ГПР по работам СМР (в сравнении с фактическими датами начала/окончания работ в ГПР); – Виджет «Мониторинг строительного контроля» должен отображать информацию о недостатках, выявленных в ходе проверок инспектором строительного контроля по всем объектам базы; – Виджет «Недостатки» должен отображать информацию о количестве недостатков, выявленных в ходе проверок строительного контроля в разбивке по их текущему статусу; – Виджет «Качество исполнительной документации» должен отображать количество документов, находящихся на согласовании, количество подписанных ЭП и количество выданных замечаний к документации; – Виджет «Стадии реализации (текущие)» должен отображать количество объектов по текущим стадиям реализации строительства, указанным в функциональном блоке «График производства работ» - 4.2.4.4.3.3. Виджеты по тематике «Управление проектами» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Статус объектов проектирования и строительства» должен отображать статус объектов; – Виджет «Актуальные вопросы (количество, статусы)» должен отображать количество и статусы по актуальным вопросам по объектам; – Виджет «Технико-экономические показатели реализуемых объектов» должен отображать сводную информацию об основных технико-экономических показателях объектов; – Виджет «Достижение КТ по общему количеству» должен отображать количество объектов по каждой КТ. При нажатии на количество объектов раскрывается таблица со списком объектов, субъектов РФ, текущей КТ, планом, фактом, «по условиям договора» (если поле заполнено) и по остальным контрольным точкам. В виджете должна быть реализована фильтрация по контрольным точкам из выпадающего списка всех КТ; – Виджет «КТ, сроки исполнения» должен отображать количество достигнутых КТ и срок которых не наступил. Виджет должен позволять выбрать контрольную точку и обеспечить фильтрацию по началу стадии или по окончанию стадии, отобразить все объекты, которые попадают в выполненные по фактической дате с информацией о выполненных ранее срока, выполненных в срок и «Не выполнено. срок истек», «Не выполнено. Срок не наступил» - 4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам - Необходимо разработать следующий функционал: – автоматическое формирование плана освоения на основании сформированного графика с отображением данных, введенных в ГПР в табличной форме по различным разрезам (стоимости и объемы работ) с возможностью выбора детализации отображения по временным периодам (день / неделя / месяц / квартал / год) и типу отображения (раздельно или накопительно) и возможностью отображения различных показателей – работы / материалы / машины и механизмы / рабочая сила и кадры; – автоматическое создание плана освоения денежных средств и физических объемов выполняемых работ в разрезах рабочей силы (чел-час), ресурсов машин и механизмов (маш-час), материалов (ед. изм.); – возможность настройки отображения показателей, а также настройки диапазона дат; – формирование графика фактического освоения денежных средств и объемов по кварталам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.10 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Необходимо разработать следующий функционал: – реализация многоуровневого списка категорий документов ПИР с предустановленными значениями категорий и возможностью добавлять категории самим пользователем в случае необходимости; – наличие предустановленных шаблонов печатных форм документов «Задание на проектирование» и «Задание на инженерные изыскания», возможность выгрузить из документа в виде текстового документа; – реализация процедур согласования и подписания с помощью ЭП документов «Задание на проектирование» и «Задание на инженерные изыскания», «Программа инженерных изысканий» с отображением статуса согласования и подписания соответствующего документа; – возможность сформировать шаблон согласования и указание информации требуется ли наличие предыдущего согласования для этого уровня для выполнения процедуры согласования; – ввод, сортировка и хранение ИРД, проектной и рабочей документации в виде вложенных файлов документации ПИР; – согласование проектной документации с отображением статуса; – формирование и ведение реестров ИРД, проектной и рабочей документации; – возможность формирования документов с сохранением версий для отслеживания изменений проектной и рабочей документации; – реализация механизма работы пользователей с замечаниями к каждому отдельному документу ПИР, ДПТ; – процедура устранения замечаний исполнителем путем возможности внесения в карточку документа в разделе работы с замечаниями ответа о результатах работы над замечанием, включая прикрепления откорректированного документа (если требуется); - 4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации) - Также на данном дашборде необходимо отобразить: – столбчатую горизонтальную диаграмму «Бюджетные обязательства/ Касса по годам», в которой должны отображаться данные показатели в разрезе по годам. Ниже должна быть отображена таблица с данной информацией; – столбчатую горизонтальную диаграмму «Авансы», отображающую информацию на текущий год: 1) всего аванса по контракту; 2) раскассировано аванса (сумма, которую Подрядчик может потратить со счета авансовых средств. Данные поступают от Подрядчика в виде сведений об операциях для утверждения. Источник данных – система «Электронный бюджет» (можно выгрузить в виде отчета в формате *xls); 3) выплачено аванса (фактическая сумма, перечисленная Подрядчику по выставленным им счетам. Данные поступают из бухгалтерии и также могут быть получены из «Электронного бюджета»); 4) остаток к выплате (показатель рассчитывается как разница между стоимостью контракта, выплаченного аванса и оплаты по КС-2 (актам выполненных работ); 5) зачтено аванса (часть суммы аванса, которая закрывается (засчитывается) при выполнении работ и подписании актов по КС-2 (акты выполненных работ). Таким образом, сумма к оплате по новым актам уменьшается на размер зачтенного аванса); 6) неотработанный аванс (сумма перечисленного аванса, которая еще не закрыта (не зачтена) актами выполненных работ (КС-2), то есть это разница между выплаченным авансом и суммой, которая уже была зачтена); – кольцевую диаграмму «Работы», с информацией по: 1) выполненным работам; 2) остатку к выполнению - 4.2.4.4.3.7. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по нескольким объектам из направления» Данный дашборд должен отображать таблицу «светофор» со списком всех объектов по направлениям и со следующими столбцами: – номер по порядку; – наименование объекта; – подрядчик (если договор расторгнут, то необходимо отобразить статус и дату, также если договор планируется расторгнуть или он в процессе расторжения); – стоимость объекта (млрд); – дата начала; – дата завершения; – готовность. Объекты должны быть распределены в таблице и окрашены в соответствующие цвета в зависимости от риска реализации объекта. При наличии риска реализации объекта строка с наименованием объекта должна окраситься в красный, при наличии умеренного риска - в желтый, при отсутствии риска - в зеленый). Требования к реализации функционального блока могут быть уточнены до окончания этапа № 1 Календарного плана - – формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы; - – процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: - – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/); - – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); - – строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/) - 4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта - Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом - Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий; - – просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»: - 4.2.4.16 Функциональный блок для ведения электронного документооборота Необходимо разработать инструмент для согласования документов, связанных с реализацией проектов. Требования к разрабатываемому функционалу функционального блока «СЭД»: – работа в СЭД с такими типами документов как: письма, контракты, закупочная документация, проектная/рабочая/исполнительная документация, соглашения, отчеты, первичные документы, приказы, протоколы, распоряжения, положения, служебные/докладные/пояснительные записки, аналитические справки, доверенности. Справочник типов документов должен быть открытый и при необходимости дополняемый; – обеспечение действий Пользователя в СЭД с документами внутреннего и внешнего, документооборота: делегирование, согласование, перенаправление, многостороннее согласование, многостороннее подписание. Реализовать возможность процедуры формирования маршрутов для согласования/подписания документов; – отображение в экранной форме Пользователя в СЭД таких параметров для каждого обрабатываемого документа, как: отправитель и получатель документа, заголовок документа, дата документа, автор документа, тип и статус обрабатываемого документа, крайний срок выполнения связанной с документом задачи. Реализовать возможность фильтрации по указанным параметрам для перечня обрабатываемых Пользователем документов; – формирование документов. Реализовать возможность устанавливать взаимосвязи создаваемых документов с уже существующими в СЭД; возможность формировать приложения к письмам для различных типов файлов, размещенных в т.ч. на ПК Пользователя; поиск по наименованию/ заголовку документа в СЭД по произвольному вводу символов для существующих в СЭД документов; содержать «Тэги» для быстрого поиска созданного письма в системе; возможность указывать метки «прочитано», «не прочитано» для входящей документации; возможность настройки Пользователем на экранной форме СЭД требуемых для отображения параметров; - – наличие истории документооборота, сохраняющего записи о всех событиях и их авторах в отношении каждого документа; – интеграция СЭД с вкладкой Планировщик задач, разделом «внутрисистемная почта» и разделом «уведомления». Организация списка документов: – создание раздела «Документы» в АРМ Подрядчика в соответствии с персональными возможностями доступа пользователя к документам; – ведение списка документов с разбивкой по процессам (этапам) и статусам документа: – карточка документа – этап для формирования карточки документа; – согласование – этап для согласования карточки документа с выделением следующих статусов: 1) на согласовании (получено согласование не от всех подписантов); 2) отменено инициатором (маршрут согласования снят инициатором); 3) согласовано (всеми подписантами); 4) отказано (получен отказ хотя бы от одного подписанта); – хранение документов с завершенным или отклоненным согласованием, организованно списком записей справочника, с предоставлением в табличном или ином виде. Должна быть реализована возможность поиска по атрибутам среди документов, доступных к просмотру: – наименование документа; – тип документа; – инициатор; – по связям с сущностями. Должна быть реализована возможность фильтрации документов по атрибутам, по этапам и статусам, по признаку «Я исполнитель», «Я инициатор», «Требует действий» - Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов - 4.2.4.13 Функциональный блок ведения строительного контроля Необходимо разработать следующий функционал: – отражение результатов проведения инспекционной деятельности (проверки); – автоматическая генерация инспекционных документов (акт проверки и предписания) на основании зафиксированных недостатков; – работа с материалами фото и видеофиксация недостатков с возможностью сформировать отчеты о проведенных проверках и количестве выявленных недостатков; – формирование актов об устранении недостатков; – подписание актов проверки, актов инспекционного контроля, предписаний об устранении недостатков/о приостановке работ, отчета по устранению нарушений (с возможностью приложения документации, отправки отчета на почту), а также актов устранения недостатков; – формирование отчета по установленной форме; – разработка программы проведения инспекционного контроля по форме; – отображение статусов карточек документов и недостатков; – автоматическое направление участникам Проекта уведомлений о выявленных недостатках; – вызов инспектора строительного контроля на Объект (Уведомление о необходимости проведения СК на объекте оформляется на официальном бланке организации Генподрядчика. - Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа; - – возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи - – доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования); - – журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - № п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии - 6 Должна содержать таблицу с информацией из графика производства работ о планировании и расходовании средств и ресурсов в рамках процесса строительства. В плане должно отображаться распределение стоимостей по периодам в разрезе стоимостей или объемов работ. 7 Должна иметь возможность формирования суточного графика работ в диапазоне дат с возможностью подневного ввода фактически выполненного объема. 8 Должна быть возможность сравнения версий, имеющих связи между собой - Необходимо разработать следующий функционал: – возможность формирования графика производства работ по проекту, в том числе на основании загруженных смет; – возможность формирования сущностей типа «запись ГПР», «Суммарная запись ГПР», «веха»; – возможность ручного добавления, удаления и перемещения по структуре работ в графике; – формирование зависимостей между работами в ГПР с установкой временных задержек; – возможность редактирования внесенного этапа работ; – назначение ответственных и исполнителей на конкретные работы графика, возможность делегирования работ; – возможность полного или частичного делегирования графика в другие версии; – возможность полуавтоматического переноса фактических показателей из делегированной версии в основную; – поддержка версионности и стадийности графиков; – возможность формирования директивной версии графика (базового плана) и заполнения новой версии ГПР на ее основании; – возможность копирования версии ГПР; – возможность сравнения связанных версий графиков между собой; – автоматический расчет критического пути с возможностью отображения только тех работ, которые принадлежат критическому пути; – автоматический расчет прогнозных сроков выполнения работ на основании динамики фактического выполнения работ; – настройка визуального отображения диаграммы Ганта; – возможность удалить этап работ из графика; - 4.2.4.4.3.5. Виджеты по тематике «Отображение аналитической информации по объектам и направлению на панели руководителя проекта» Группа виджетов должна отображать текущие показатели по объекту направления. У группы виджетов должен быть предусмотрен фильтр по направлениям (воздушный транспорт, железнодорожный транспорт, морской транспорт, речной транспорт): – стоимость контракта; – дефицит (отображает разницу между доведенными лимитами и стоимостью объекта по ССР); – непогашенный аванс (разница между суммой выданного аванса и погашенного по КС-3); – банковская гарантия с указанием даты завершения (из контрактов); – строительная готовность объекта, отображаемая в процентах, и динамика за неделю по задействованным трудовым ресурсам (чел.) и машинах и механизмах (в ед.); – характеристика объекта; – эффекты, которые оказывает объект строительства; – необходимые решения; – ход исполнения; – фотография объекта. Также по объекту из направления должна отображаться таблица с диаграммой Ганта со столбцами: – номер по порядку; – наименование объекта; – длительность (дней); – начало (дата); – окончание (дата); – диаграмма с разделением по кварталам. Виджет «Отчет по объекту» должен содержать три окна: – в первом окне – «Эффект от реализации»; – во втором окне – «Информация об объекте/Проблемные моменты» со следующим перечислением: 1) поле «Заключен ГК» (необходимо указать юридическое лицо, с которым заключен контракт), далее необходимо показать вид работ из контракта, дату заключения договора и номер контракта; 2) отображение информации о текущей контрольной точке объекта и плановой дате; 3) информация по контракту (дорожная карта); 4) дата ввода объекта в эксплуатацию с комментарием); 5) поле «Виды работ»; 6) изменения количества рабочих/техники с разбивкой по месяцам с даты начала СМР; – в третьем окне – «Предложения по решению проблем» - 4.2.5 Общие требования к функционированию - 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ - - Значение характеристики не может изменяться участником закупки - 4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02 - 4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы - 4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана - 4.2.5.3 Требования к обмену сообщениями В рамках выполнения Работ реализуется встроенный мессенджер, позволяющий обмениваться сообщениями между пользователями АРМ. Требования к разрабатываемому функционалу: – создание персональных чатов из списка пользователей из раздела мессенджера; – создание групповых чатов из раздела мессенджера; – возможность отправки текстовых сообщений и файлов; – поиск по списку чатов; – возможность удаления созданного чата; – корректировка перечня участников группового чата; – индикация групповых чатов в списке - 4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования - 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления - - Значение характеристики не может изменяться участником закупки - 4.3.5 Требования по применению систем управления хранилищами и базами данных Для хранения данных должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. Допускается размещение отдельных параметров конфигурации Системы, не подлежащих модификации в ходе ее нормального функционирования и обслуживания, во внешних конфигурационных файлах. Общие требования к используемой реализации СУБД: – наличие сертификата соответствия ФСТЭК России требованиям по защите информации, предъявляемым к системам управления базами данных не ниже 5 класса защиты; – поддержка реляционной или объектно-реляционной модели базы данных; – поддержка технологии клиент-сервер; – поддержка многопроцессорной архитектуры; – наличие средств создания индексов и кластеров данных; – автоматическое восстановление базы данных; – совместимость с различными операционными системами серверов БД; – поддержка сетевых протоколов TCP/IP; – наличие графических средств администрирования; – возможность контроля доступа к данным; – централизованное управление учетными записями пользователей; – оптимизация запросов - 1) Решение должно быть совместимо с программными продуктами и операционными системами, применяемыми в технологической в инфраструктуре Заказчика. Точный перечень ПО и версий ОС уточнять у технических специалистов Заказчика. 2) Допускается использование только кластеризованных баз данных. Должна быть реализована поддержка механизмов кластеризации, которые применяются в инфраструктуре Заказчика. 3) Решение должно быть отказоустойчивым. Отказоустойчивость решения реализуется самим решением, или на уровне отдельных его компонентов. 4) Любые соединения, устанавливаемые решением, должны быть защищенными*. Примечания: 1 Защищенные соединения, выходящие за пределы контролируемой зоны, должны быть защищены с помощью программных и/или программно-аппаратных шифровальных (криптографических) средств, сертифицированных ФСБ России (далее – СКЗИ). 2 Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД; 5) Любая сервисная учетная запись, которая используется в решении, должна обладать минимально необходимыми привилегиями для выполнения возложенных на нее задач. Использование учетных записей с административными полномочиями не допускается - 4.3.2 Требования к организации хранилища данных Для хранения информации должна использоваться СУБД с возможностями распределенного хранения данных по кластерным узлам. СУБД предоставляется Заказчиком после завершения этапа № 1 Календарного плана. Структура БД должна быть организована рациональным способом, исключающим единовременную полную выгрузку информации, содержащейся в БД Системы. При проектировании структуры БД для хранения данных необходимо провести анализ реализованной структуры БД для П-МКП в целях использования в создаваемых АРМ. В результате анализа Подрядчик обязан представить Заказчику в Пояснительной записке описание структуры БД для функционирования АРМ с указанием переиспользуемых и вновь создаваемых таблиц БД. Информация должна размещаться в БД по возможности в нормализованной форме. Допускается использование дополнительных ненормализованных структур данных для повышения производительности. Допускается размещение отдельных параметров конфигурации во внешних конфигурационных файлах. Допускается размещение данных в нереляционных СУБД в случаях, предусматривающих очевидную выгоду в производительности, оптимизации требуемого места для хранения данных или необходимых вычислительных ресурсах по согласованию с Заказчиком. Полный перечень используемых программных решений должен быть определен Подрядчиком и согласован Заказчиком на этапе № 1 Календарного плана - 4.3.4 Требования к информационному обмену между компонентами Системы Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет - 5 Состав и содержание работ по развитию АСУ ТК - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) - - Значение характеристики не может изменяться участником закупки - 5.1 Состав работ и график их выполнения (календарный план) - 2 Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Разработка новой функциональности Системы. Развертывание, настройка функциональных блоков. Разработка документации на П-МКП. Предварительные испытания. Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 Сопроводительным письмом предоставлены Заказчику: Исходные коды разработанного (передаваемого) программного обеспечения; Дистрибутивы разработанного (передаваемого) программного обеспечение; Инструкция по сборке; Паспорт П-МКП; Описание П-МКП; Руководство администратора; Руководства пользователей на каждый АРМ, включая рекомендуемые характеристики к ПК для АРМ; Документы по испытаниям в составе: - Программа и методика предварительных испытаний; - Протокол предварительных испытаний; - Программа и методика опытной эксплуатации; - Акт ввода в опытную эксплуатацию; - Ведомость эксплуатационных документов; - Ведомость машинных носителей информации; - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с 01.02.2026; Окончание: не позднее 30.04.2026 - - Значение характеристики не может изменяться участником закупки - 3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026 - 1.3. Разработка макетов Начало: 26.01.2026 Окончание: не позднее 31.01.2026 Сопроводительным письмом предоставлены Заказчику: - графические макеты пользовательских экранных форм (интерфейсов) и аналитических панелей (виджетов); - Документ о приемке по этапу. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). Начало: с даты заключения Контракта; Окончание: не позднее 31.01.2026 - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты работ (программное обеспечение) предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Сроки, установленные Календарным планом для каждого подпункта в рамках этапов, согласно таблице 11, включают подготовку, согласование, утверждение (для тех документов, в отношении которых требуется согласование или утверждение) отчетных, технических, рабочих документов с Заказчиком. Досрочная сдача результатов допускается по согласованию с Заказчиком. Сокращение периода (длительности) проведения опытной эксплуатации недопустимо. График выполнения работ по развитию АСУ ТК приведен в таблице 11. Таблица 11 – График выполнения работ по развитию АСУ ТК - № этапа Наименование этапа Наименование видов работ в рамках этапа Срок исполнения подпункта в рамках этапа Ожидаемые результаты работ 1 Техническое проектирование. 1.1. Разработка частного технического задания Начало: с даты заключения контракта Окончание: не позднее 19.01.2026 Сопроводительным письмом предоставлены Заказчику: Частное техническое задание. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 1.2. Разработка технического проекта Начало: 19.01.2026 Окончание: не позднее 26.01.2026 Сопроводительным письмом предоставлены Заказчику: Технический проект в составе: - Описание архитектуры системы; - Пояснительная записка, включая описание автоматизируемых функций; - Описание программного обеспечения; - Описание информационного обеспечения; - Ведомость технического проекта; - Ведомость машинных носителей информации; - Руководство по безопасной разработке программного обеспечения. Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 3 (трех) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу) - 6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации - Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ - - Значение характеристики не может изменяться участником закупки - 6.2 Виды, состав, объем и методы испытаний и его составных частей - В случае выявления ошибок в ПО П-МКП при проведении предварительных испытаний, Подрядчик должен их устранить до начала момента проведения опытной эксплуатации. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки). Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены Подрядчиком в документе «Программа и методика опытной эксплуатации». Программа и методика опытной эксплуатации должна быть утверждена Заказчиком до проведения опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Отчет о проведении опытной эксплуатации» (с приложением журнала опытной эксплуатации) и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации, подтверждающий готовность П-МКП АСУ ТК и ее допуск к приемочным испытаниям - - Значение характеристики не может изменяться участником закупки - Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный - Результаты проведения предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от ТЗ оформляются как недостатки работ. Прочие недостатки могут документироваться как рекомендации. Наличие рекомендаций не влияет на процесс передачи П-МКП АСУ ТК в эксплуатацию. В случае значительного отклонения П-МКП АСУ ТК от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены или расширены Заказчиком. По результатам выполнения этапа № 3 должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Предварительные и приемочные испытания, опытная эксплуатация проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии и сроки проведения испытаний. Испытания проводятся на площадке, указанной в программе и методике соответствующих испытаний, опытной эксплуатации. В состав комиссии включаются ответственные лица Заказчика и Подрядчика, а также, при необходимости, специалисты иных внешних организаций (например, экспертных), привлекаемые Заказчиком. Подрядчик обязан уведомить Заказчика о готовности к проведению испытаний официальным сопроводительным письмом и предоставить Заказчику программу и методику испытаний (далее – ПМИ). Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком и Подрядчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытаний и Акт о приемке в опытную эксплуатацию, подтверждающий готовность П-МКП АСУ ТК к следующему виду испытаний – опытной эксплуатации - Состав мероприятий, включенных в пилотную зону, может быть изменен по согласованию с заказчиком. В случае выявления ошибок в ПО П-МКП при проведении опытной эксплуатации, Подрядчик должен их устранить до начала приемочных испытаний. Также Подрядчик должен скорректировать документацию на Систему (в случае необходимости такой корректировки) Методы приемочных испытаний и порядок их проведения должны быть определены в документе «Программа и методика приемочных испытаний», который должен быть подготовлен Подрядчиком и утвержден Заказчиком до начала приемочных испытаний. По результатам проведения приемочных испытаний оформляются Протокол приемочных испытаний и Акт готовности П-МКП к эксплуатации. В Протоколе приемочных испытаний должны быть указаны перечень проверяемых сервисов, функций, возможностей, дата и время проведения приемочных испытаний, состав приемочной комиссии, рекомендации (при наличии) к решению, а также выводы о готовности П-МКП АСУ ТК к вводу в эксплуатацию. Ввод П-МКП АСУ ТК в эксплуатацию осуществляется после выполнения работ по ИБ, подписанием соответствующего акта - 6.3 Порядок контроля и приемки выполненных работ - Сдача-приемка выполненных работ осуществляется в соответствии с условиями Контракта. Сдача-приемка работ осуществляется по завершении каждого этапа в порядке, установленном в Контракте - - Значение характеристики не может изменяться участником закупки - 6.3.1 Условия о порядке предоставления (передачи) результатов выполнения работ Заказчику - Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса компиляции, создания дистрибутива и установки (развертывания) разработанных программ для ЭВМ, а также в соответствии с инструкциями, приведенными в рабочей документации на П-МКП. Документация на П-МКП и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика - - Значение характеристики не может изменяться участником закупки - Передача исходных кодов, разработанных и/или передаваемых в ходе выполнения работ программ для электронных вычислительных машин (далее - программа для ЭВМ) и дистрибутивов должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, инструкций и программных сценариев (скриптов) для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ. Для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ должны использоваться свободно распространяемые компиляторы, интерпретаторы и иное программное обеспечение, необходимое для указанных целей, дистрибутивы которых должны быть переданы вместе с исходными кодами разработанных и/или передаваемых в ходе выполнения работ программ для ЭВМ. В случае использования для проведения компиляции, создания дистрибутива и установки (развертывания) программы для ЭВМ компиляторов, интерпретаторов и иного программного обеспечения, права на использование, копирование и модификацию которых принадлежат третьим лицам, Подрядчик за свой счет передает заказчику исходные коды, дистрибутивы и права на использование таких компиляторов, интерпретаторов и иного программного обеспечения. - 6.4 Сведения о гарантийном обслуживании - Гарантийный срок: один год с даты подписания Заказчиком документа о приемке Этапа № 3. Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, включая замечания и комментарии от федеральных органов исполнительной власти в области обеспечения безопасности, федерального органа исполнительной власти, уполномоченного в области противодействия техническим разведкам и технической защиты информации, Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, Министерства транспорта Российской Федерации и Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций, выявленных после приемки выполненных Работ, в том числе в документации, разработанной по результатам выполненных Работ, касающиеся соответствия требованиям нормативных правовых актов, действующих на момент завершения этапа № 2. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик (в случае, если не докажет отсутствие своей вины) обязан устранить их за свой счет в сроки, установленные Заказчиком в Акте с перечнем выявленных недостатков. Гарантийный срок в этом случае соответственно продлевается на период устранения недостатков. Гарантийным случаем признается полное или частичное отсутствие функционирования П-МКП и ее компонентов в результате выполнения работ по настоящему Техническому заданию. Подрядчик должен обеспечить гарантию работоспособности П-МКП, включая гарантийную поддержку - - Значение характеристики не может изменяться участником закупки - В рамках гарантийной поддержки П-МКП Подрядчик должен: – устранять обнаруженные в процессе постоянной эксплуатации дефекты в работе П-МКП в срок не более 5-ти рабочих дней (в случае необходимости данный срок может быть увеличен по согласованию с Заказчиком); – принимать участие в восстановлении работоспособности П-МКП после сбоев и аварий, вызванных дефектами и недокументированными возможностями подсистемы, выполняя при этом работы, связанные с восстановлением целостности данных и обновлением П-МКП; – вносить изменения в техническую и рабочую документацию на функциональные блоки, на основании выявленных неточностей или обнаруженных недокументированных возможностей подсистемы; – консультировать представителей Заказчика об особенностях реализации П-МКП, в том числе при установке, настройке и пуско-наладке Системы; – давать ответ на заявку Заказчика в течение 1 (Одного) рабочего дня с момента ее поступления - 7 Источники разработки - Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки - Приложение А к Техническому заданию - Таблица А.1 – Описание состава загружаемых данных по мероприятиям Раздел данных Подраздел данных Название атрибута Общая информация об объекте - Наименование Федерального проекта - Инвестпроект - Участок - Длина участка, км Провозная способность, млн. тонн в год план факт Пропускная способность, пар поездов в сутки план факт Максимальная весовая норма поездов, тонн план факт - Наименование мероприятия/объекта - Код объекта - Ответственный исполнитель/ заказчик (контакты) - Субъект Российской Федерации/фактическое (местоположение объекта) - Код ИП - Назначение объекта, основные характеристики объекта (ТЭП) - Предварительная стоимость по ФП (млн. руб.) Ход реализации (Проектирование) Заключен контракт на инженерные изыскания ПД план факт Направление ПД на ГГЭ план по условиям договора факт Получение заключения государственной экспертизы на ПСД план по условиям договора факт стоимость по итогам заключения ФАУ «Главгосэкспертиза России» - Сроки по ПОС Ход реализации (Строительство) Проведение конкурсных процедур на выполнение СМР Объявление торгов (план) Объявление торгов (факт) Заключение контракта на СМР (план) Заключение контракта на СМР (факт) Оформление земельно-правовых отношений* план факт выполнение в % Получено РС план факт Ввод объекта во временную эксплуатацию план факт Получен ЗОС план факт Ввод объекта в эксплуатацию (РВ) план по условиям договора* факт отклонение (дни) - Примечание Обеспеченность машинами и механизмами - план факт - - Строительная готовность (в %) Привлечение трудовых ресурсов, чел. - план факт - - Уровень риска реализации (определяется по наличию отставаний по контрольным точкам, влияющих на срок ввода в эксплуатацию) Объем финансирования в соответствии с ФП (млн. руб.) Год, по которому сформирован отчет Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Сводная бюджетная роспись на отчетную дату - - Значение характеристики не может изменяться участником закупки - Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) - Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства

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

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

ФП КПМИ Федеральная программа «Комплексный план модернизации и расширения магистральной инфраструктуры» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЦОД Центр обработки данных ЦХД Централизованное хранилище данных ЧТЗ Частное техническое задание ЭВМ Электронная вычислительная машина ЭП Электронная подпись API Application Programming Interface, набор способов и правил, по которым различные программы общаются между собой и обмениваются данными application instance экземпляр программного приложения, являющийся уникальным вызовом запуска приложения. FTP File Transfer Protocol, протокол передачи файлов по сети от одного физического устройства на другое HTTP HyperText Transfer Protocol, протокол прикладного уровня передачи данных HTTPS Hypertext Transfer Protocol Secure — расширение протокола HTTP, поддерживающее шифрование git2git Метод копирования репозиториев исходного кода ПО между различными стендами (контрами) разработки, тестирования и функционирования REST Representational State Transfer — способ создания API с помощью протокола HTTP TCP/IP Набор сетевых протоколов разных уровней. Протоколы работают друг с другом в стеке, что означает, что протокол, располагающийся на уровень выше, работает «поверх» нижнего, используя механизмы инкапсуляции QR-код Двухмерный штриховой код (от англ. «Quick Response» – «быстрый отклик»)

1 Общие сведения 1.1 Наименование системы - Полное наименование системы: информационно-аналитическая система регулирования на транспорте (АСУ ТК). Условное обозначение системы: АСУ ТК (далее – АСУ ТК, Система), Подсистема «Мониторинга комплексного плана» (далее - П-МКП). Наименование работ: выполнение работ по импортозамещению и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК), далее, соответственно – Функционал, Работы. Код по ОКПД2: 62.01.11.000 - услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Работы, проводимые в рамках данного ТЗ предусмотрены в составе ИТ-расхода № 103.26.000124 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в части мероприятий по импортозамещению подсистемы «Мониторинга комплексного плана» и внедрению функционала «Цифровое управление строительством» предусмотренного в ВПЦТ Минтранса России на период 2026-2028. - - Значение характеристики не может изменяться участником закупки

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

1.3 Основания для выполнения работ - 1. Перечень поручений Президента Российской Федерации от 05.06.2021 г. № Пр-950 «Перечень поручений по вопросам развития Байкало-Амурской и Транссибирской магистралей на территориях Сибирского Федерального округа и Дальневосточного Федерального округа»; 2. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-8035 от 21.06.2021 г.; 3. Перечень поручений Заместителя Председателя Правительства Российской Федерации Хуснуллина М.Ш. №МХ-П49-17542 от 02.12.2021 г; 4. Распоряжение Министерства транспорта Российской Федерации от 27.102.2025 № АН-264-р «Об импортозамещении и реализации функционала цифрового мониторинга и координации строительных работ объектов транспортной инфраструктуры в информационно-аналитической системе регулирования на транспорте (АСУ ТК)» 5. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 6. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 7. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 8. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 9. Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; - - Значение характеристики не может изменяться участником закупки

10. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 11. Постановление Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 12. Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» (с изм. и доп., вступ. в силу с 01.01.2019); 13. Постановление Правительства Российской Федерации от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия»; 14. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 15. Положение о Министерстве транспорта Российской Федерации, утвержденное постановлением Правительства Российской Федерации от 30.07.2004 № 395; 16. Концепция создания автоматизированной системы управления транспортным комплексом (АСУ ТК). Одобрена на заседании президиума Совета при Президенте Российской Федерации по развитию информационного общества в Российской Федерации 29.09.2010;

17. Распоряжение Минтранса России от 30.12.2016 № МС 203-р «Об обеспечении эксплуатации первой очереди информационно-аналитической системы государственного регулирования на транспорте (АСУ ТК)»; 18. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 19. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 20. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 21. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 22. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия»

1.4 Перечень документов, требования которых должны быть учтены при выполнении работ - 1. Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; 2. Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; 3. Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; 4. Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; 5. Постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации»; 6. Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (действителен до 01.03.2026); 7. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»; 8. Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; 9. Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений» (вступает в силу с 01.03.2026); 10. Приказ Минкомсвязи России от 23.06.2015 № 210 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» - - Значение характеристики не может изменяться участником закупки

11. ГОСТ 2.004-88 «Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ»; 12. ГОСТ Р 2.051-2023 «Единая система конструкторской документации. Электронная конструкторская документация. Общие положения»; 13. ГОСТ 2.102-2023 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»; 14. ГОСТ Р 2.104-2023 «Единая система конструкторской документации. Основные надписи»»; 15. ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам»; 16. ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы»; 17. ГОСТ 2.113-75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»; 18. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»; 19. ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы»; 20. ГОСТ 2.701-2008 «Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению»; 21. ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»; 22. ГОСТ Р 15.011-2024 «Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 23. ГОСТ 19.101-2024 «Единая система программной документации. Виды программ и программных документов»; 24. ГОСТ 19.103-77 «Единая система программной документации. Обозначение программ и программных документов»;

25. ГОСТ 27.003-2016 «Надежность в технике. Состав и общие правила задания требований по надежности»; 26. ГОСТ Р 27.301-2011 «Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения»; 27. ГОСТ 34.201–2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»; 28. ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы; 29. ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»; 30. ГОСТ Р 59792–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем»; 31. ГОСТ Р 59793–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; 32. ГОСТ Р 59795–2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»; 33. Рекомендации по стандартизации Р 50.1.053-2005 Информационные технологии. Основные термины и определения в области технической защиты информации

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

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

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

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

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

2.2 Цели развития Системы - Целями развития Системы, согласно данному ТЗ, является выполнение работ по импортозамещению и развитию текущей версии подсистемы «Мониторинга комплексного плана» (П-МКП), реализованной на базе иностранного программного обеспечения (Microsoft, Oracle), путем разработки П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

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

2.3 Состав выполняемых задач - Для реализации указанных в пункте 2.2. ТЗ целей, необходимо выполнить импортозамещение и развитие П-МКП, с использованием отечественного программного обеспечения, соответствующего требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

В результате развития подсистемы «Мониторинга комплексного плана» (П-МКП), на основе отечественного программного обеспечения, должно быть обеспечено создание новых функций: 1) автоматизация процессов формирования аналитики и паспортизации проектов и объектов; 2) автоматизация процессов формирования и ведения календарно-сетевого планирования; 3) автоматизация процессов ведения проектно-изыскательских работ; 4) автоматизация процессов ведения сметной документации; 5) автоматизация процессов формирования и ведения исполнительной документации; 6) автоматизация процессов ведения строительного контроля; 7) организация формирования отчетов; 8) автоматизация ведения договоров; 9) создание функционала для просмотра и работы с BIM-моделированием; 10) разработка функциональной возможности формирования бизнес-процессов; 11) автоматизация процессов формирования и реализации задач; 12) реализация информационных панелей (дашбордов) о ходе выполнения национальных и федеральных проектов в зоне ответственности Минтранса России, содержащих информацию в разрезе по объектам транспортной инфраструктуры и иным объектам, находящимся в ведении Минтранса России, их видам, местоположению, заказчикам, срокам реализации, источникам финансирования и иным подлежащим мониторингу параметрам; 13) автоматизация расчета и визуализации достижения контрольных точек реализации мероприятий по строительству (реконструкции) объектов транспортной инфраструктуры и иных объектов, находящихся в ведении Минтранса России, в том числе в разрезе по годам, виду, статусам достижения; 14) обеспечение системы оповещений о рисках и отклонениях от плановых показателей; 15) организация ведения реестра объектов строительства (реконструкции) с полной историей изменений, включая запись соответствующих действий пользователей

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

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

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

1 Подсистема сбора данных и централизованное хранилище данных П-СД 2 Подсистема информационного взаимодействия (П-ИВ) и Модуль системы межведомственного электронного взаимодействия П-ИВ, Модуль СМЭВ 3 Геоинформационная подсистема П-ГИС 4 Подсистема ведения нормативно-справочной информации и метаданных П-НСИ 5 Подсистема информационного портала ПСД-ПАСУ 6 Подсистема технического портала ПСД-ТЕХ 7 Подсистема проектного архива ПСД-ПАР 8 Портал администрирования АСУ ТК - 9 Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс Модуль iМинтранс 10 Модуль «Контроль состояния городского электрического транспорта и объектов транспортной инфраструктуры» Модуль ГЭТ 11 Модуль «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте» Модуль СЦ 12 Модуль мониторинга - 13 Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФЗ «Реестр объектов» 14 Функциональная задача «Информационно-аналитическая поддержка процессов территориального планирования Российской Федерации в области федерального транспорта» ФЗ «СТП» 15 Функциональная задача «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» ФЗ «МРТБ ПП» 16 Функциональная задача «Мониторинг дорожного движения» ФЗ «МДД» 17 Функциональная задача «Формирование и ведение транспортного паспорта региона» ФЗ «ТПР» 18 Функциональная задача «Обеспечение подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами» ФЗ «Данные по грузообороту» 19 Функциональная задача «Мониторинг железнодорожного транспорта» ФЗ «МЖТ» 20 Функциональная задача «Мониторинг грузопотоков в морских портах» ФЗ «МГМП» 21 Витрина данных НСУД - 22 Подсистема «Мониторинга комплексного плана» П-МКП

3.2.1. Состав используемого ПО - Подсистема сбора данных (П-СД) включает: – Postgres Pro Enterprise – объектно-реляционная система управления БД, используемая для создания оперативного хранилища данных (представляет из себя единый и неделимый компонент); – ClickHouse – система управления БД для выполнения аналитических запросов на больших объемах данных (представляет из себя единый и неделимый компонент); – Apache Hadoop – распределенная файловая система для хранения файлов больших объемов данных, используемая для формирования исторического хранилища данных (представляет из себя единый и неделимый компонент). В работе П-СД используются программные компоненты Apache: – HBase Apache; – Hive Apache; – Kafka Apache; – Ranger Apache; – Solr Apache; – Spark Apache; – ZooKeeper Apache. Информационный портал АСУ ТК – компонент, отвечающий за предоставление веб-интерфейса пользователю для взаимодействия с данными из подсистем АСУ ТК и модуль администрирования, отвечающий за настройку и управление данными, отображаемыми в Информационном портале АСУ ТК. Включает в себя следующие сервисы: – сервис формирования схем Graphql – построение схемы для graphql по результатам изменения в портале администрирования отчетами; – сервис брокера задач – служебный обмен и взаимодействие микросервисов; – сервис интерфейса формирования меню и отчетов – кэширование отчетов и меню ФЗ из ЦХД во временное хранилище при изменении через портал администрирования или микросервисы; – сервис фильтрации данных – построение, кэширование форм фильтрации, применимых в отчетах ФЗ. Технический портал АСУ ТК (далее – ПСД-ТЕХ) – компонент, отвечающий за обработку заявок на техническую поддержку, поступающих от пользователей Информационного портала АСУ ТК, и отправляющий полученные данные в ПСД-ТЕХ. Подсистема технического портала представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. - - Значение характеристики не может изменяться участником закупки

Проектный архив АСУ ТК – компонент, отвечающий за отображение документов проектного архива, их структуризацию и предоставление данных пользователям Информационного портала. Подсистема проектного архива представлена в виде настроенного ПО «Байтим», разворачиваемого на сервере. Подсистема ведения нормативно-справочной информации и метаданных является неделимым программным продуктом. Разделение возможно только на логическом уровне на следующие модули: – модуль импорта и экспорта данных; – модуль управления нормативно-справочной информацией; – модуль отчетности. Подсистема информационного взаимодействия (П-ИВ) состоит из следующих программных компонентов: – Apache AirFlow – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Great Expectations – компонент, отвечающий за контроль качества данных, загружаемых через Apache AirFlow; – Apache Atlas – компонент, отвечающий за хранение метаданных, каталогизирование данных и создание моделей; – Graph QL – компонент, отвечающий за создание витрин данных и отвечающий за предоставление данных подсистемам; – GIMS Portal – компонент для настройки GIMS Automation через веб-интерфейс; – GIMS Automation – компонент, отвечающий за обеспечение оркестровки операций по обработке данных. В процессе работы компонент обеспечивает интерфейс для решения оперативных задач по интеграции с внешними системами и осуществляет загрузку или выгрузку данных в ЦХД АСУ ТК; – Модуль СМЭВ – компонент, отвечающий за осуществление взаимодействия с системой СМЭВ. Компонент принимает запросы, которые должны быть отправлены в СМЭВ, и осуществляет их трансформацию в формат, необходимый для взаимодействия со СМЭВ

Геоинформационная подсистема включает следующие компоненты: – NextGIS Web – это серверная ГИС, которая предоставляет возможность хранения и редактирования геоданных, просмотра в веб-браузере карт; – NextGIS Geoservices – это веб-приложение, предназначенное для управления сервисами геоданных, к которым в первую очередь относятся тайловые сервисы. NextGIS Geoservices предоставляет доступ к картам по протоколу TMS. Функциональные задачи и пользовательские модули используют для функционирования ПО подсистем П-СД, П-ИВ, П-ГИС, П-НСИ и порталов. В составе модуля iМинтранс используется ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», предназначенная для анализа данных с помощью настраиваемых интерактивных аналитических панелей, включающих большой набор графических элементов (виджетов). Текущая версия П-МКП реализована с учетом необходимости использования ПО иностранного производства (Microsoft, Oracle). Поэтому в рамках данного ТЗ предусмотрены мероприятия по импортозамещению, предполагающие разработку версии П-МКП соответствующей требованиям постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». В рамках отдельных мероприятий (закупочных процедур) и заключения отдельных Контрактов, планируется приобретение ПО и оборудования, соответствующих требованиям по импортозамещения с целью установки и настройки доработанной версии П-МКП (не является частью данного ТЗ)

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

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

3.3.2. Информационные объекты - Проектная документация (технические задания, чертежи, сметы). Рабочая документация (графики выполнения работ, спецификации). Исполнительная документация (акты выполненных работ, журналы строительства). Реестры объектов транспортной инфраструктуры и их характеристик (местоположение, технические параметры, статус). Данные мониторинга (сроки, бюджеты, КПЭ, риски) - - Значение характеристики не может изменяться участником закупки

3.3.3. Процессы автоматизации - Хранение документов с учетом версионности и истории изменений. Сбор данных о ходе строительства (факт/план по срокам, бюджетам, выполненным работам). Анализ отклонений и рисков с формированием уведомлений для ответственных лиц. Формирование аналитических отчетов для принятия управленческих решений. Формирование аналитических информационных панелей (дашбордов) для приоритизации и визуализации данных - - Значение характеристики не может изменяться участником закупки

3.3.4. Взаимодействие участников - Обмен данными с внешней системой должен обеспечиваться посредством импорта отчета в формате *xls по защищенным каналам связи, предоставляемым Заказчиком. Должна быть обеспечена загрузка данных, в том числе сведений об объектах из карточек (паспортов) инвестиционно-строительных объектов, об этапах реализации объектов (контрольных точках) и их актуальных статусах - - Значение характеристики не может изменяться участником закупки

4 Требования к Работам - Создание функционала для контроля строительства (реконструкции) осуществляется на основе подсистемы «Мониторинга комплексного плана» АСУ ТК, а именно в части, указанной в п. 3.1, 3.2 ТЗ и является развитием Системы - - Значение характеристики не может изменяться участником закупки

4.1 Требования к развитию Системы в целом 4.1.1 Требования к структуре - 11 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.4.6 12 Функциональный блок подготовки и передачи данных Информационно-аналитический контур должен использовать полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности п.п. 4.2.4.7 13 Функциональный блок «Информация» Функциональный блок должен содержать основные сведения (цели, сроки реализации, бюджет, перечень участников, ответственных лиц и исполнителей по объекту, текущий статус и другие атрибуты, информацию об объекте в виде графических виджетов и табличных списков) п.п. 4.2.4.8 14 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования и выполнения календарно-сетевого планирования п.п. 4.2.4.9 15 Функциональный блок для ведения проектно-изыскательских работ «ПИР» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов выполнения проектно-изыскательских работ и работ с проектной/рабочей документацией на этапе предпроектной и проектной реализации п.п. 4.2.4.10 16 Функциональный блок для ведения сметной документации Функционального блок предназначен для автоматизации отдельных бизнес-процессов для работы со сметной документацией п.п. 4.2.4.11 - - Значение характеристики не может изменяться участником закупки

17 Функциональный блок для формирования и ведения исполнительной документации Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания исполнительной документации, журналов производства работ, документов по ПНР в электронном виде п.п. 4.2.4.12 18 Функциональный блок ведения строительного контроля Функциональный блок предназначен для автоматизации отдельных бизнес-процессов формирования, ведения и подписания инспекционных документов, формируемых органами, осуществляющими строительных контроль в электронном виде п.п. 4.2.4.13 19 Функциональный блок ведения договоров «Управление проектом» Функциональный блок предназначен для автоматизации отдельных бизнес-процессов, связанных с ведением контрактов по объекту/проекту, управлением сроками реализации проекта. п.п. 4.2.4.14 20 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функции BIM (информационного 3D моделирования) п.п. 4.2.4.15 21 Функциональный блок для ведения электронного документооборота Функциональный блок предназначен для автоматизации отдельных бизнес-процессов функциям электронного документооборота п.п. 4.2.4.16 22 Функциональный блок для формирования и реализации задач Функциональный блок предназначен для автоматизации отдельных бизнес-процессов по формированию и реализации задач п.п. 4.2.4.17

Состав функциональных блоков может быть скорректирован на этапе № 1 Календарного плана исключительно по согласованию с Заказчиком.

В рамках работ по настоящему ТЗ необходимо создать АРМ Сотрудника, АРМ Подрядчика, АРМ Заказчика и функциональные блоки, обеспечивающие доступ к П-МКП. Выполнение работ не должно привести к изменениям функционала всех ранее созданных подсистем АСУ ТК. В рамках данных работ интеграция с другими подсистемами АСУ ТК не предполагается. Структура АРМ и блоков должна обеспечить функционирование двух контуров, имеющих разное функциональное назначение: – информационно-аналитический контур; – функциональный контур. При разработке контуров требуется использовать одинаковые подходы к построению архитектуры подсистем, которые не противоречат основным требованиям, применяемым при проектировании подсистем АСУ ТК. Для каждого контура следует предусмотреть следующие уровни: – уровень приложения; – уровень хранения данных, в т.ч. ведение нормативно-справочной информации; – уровень информационного взаимодействия; – уровень файлового хранения; – уровень работы микро- и макросервисов. Уровень приложения: – поддержка разделения на различные функциональные модули; – поддержка гибко настраиваемой ролевой модели; – отдельно вынесенный функционал базовых операций и формирования стандартных элементов интерфейса; – неограниченное количество конфигураций в рамках одного application instance, обеспечивающих выделенную среду работы группам пользователей

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

4.1.1.1 Перечень функциональных блоков, их назначение и характеристики В таблице 2 указаны функциональные блоки, их назначение и ссылки на пункты ТЗ, в которых раскрываются функциональные требования к ним. Таблица 2 – Перечень развиваемых функциональных блоков

№ Наименование АРМ/функционального блока Назначение Требование 1 АРМ Сотрудника АРМ должно обеспечивать оперативный сбор и показ аналитической информации на основе внешних источников п.п. 4.2.3.1 2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для визуального отображения основных показателей объекта/проекта п.п. 4.2.3.2 3 Функциональный блок отчетности Функциональный блок формирования отчетов должен обеспечивать поддержку процедур сбора отчетной информации по проектам в различные отчеты п.п. 4.2.3.3 4 Функциональный блок загрузки данных Функциональный блок должен обеспечивать получение (загрузку) в информационно-аналитический контур актуальных данных по проектам, объектам п.п. 4.2.3.4 5 АРМ Подрядчика АРМ должно позволять Подрядчику вносить объем данных, связанных с реализацией проекта п.п. 4.2.4.1 6 АРМ Заказчика АРМ должно включать в себя набор функционала для работы с объектами строительства и управления сотрудниками со стороны заказчика доступом к АРМ Подрядчика для сотрудников подрядчиков п.п. 4.2.4.2 7 Функциональный блок ЭП Функциональный блок должен позволять подписывать документы электронной подписью п.п. 4.2.4.3 8 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен быть предназначен для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.) п.п. 4.2.4.4 9 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок должен давать возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденным Минстроем РФ для передачи и подписания документов в электронном виде п.п. 4.2.4

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

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

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

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

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

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

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

4.1.6 Требования к транспортабельности - Не предъявляются - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.1.10 Требования к безопасности исходного кода - Заказчик предоставляет Подрядчику Руководство по безопасной разработке ПО (далее - Методика), применяемое при разработке исходного кода разработанного функционала (результата работ по настоящему контракту). Подрядчик обязуется обеспечить реализацию процесса разработки исходного кода, не противоречащего ГОСТ Р 56939-2024 и Методике, а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику в сроки, установленные Календарным планом, отчетные материалы, в том числе акты инструментальных проверок исходного кода разрабатываемого функционала (результата работ по настоящему контракту), в соответствии с Методикой, и исходный код для тестирования защищенности разработанного функционала (результата работ по настоящему контракту) и выявления уязвимостей в исходном коде разработанного функционала (результата работ по настоящему контракту) с применением методов статического и динамического анализов, а также анализа сторонних компонентов. Подрядчик предоставляет исходный код разработанного функционала (результата работ по настоящему контракту) Заказчику с помощью использования подхода git2git. Предоставление отчетных материалов осуществляется путем их направления на почту ответственных лиц. Загруженный исходный код должен сопровождаться необходимым набором инструкций для развертывания экземпляра ПО и/или опытного образца ПО - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.1.13.7. Передача Заказчику исключительных прав или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.1.13.8. Независимо от использования/не использования Подрядчиком при выполнении Работ ПО, указанного в п. 4.1.13.6 ТЗ, функциональность Системы передается в объеме и в сроки, установленные ТЗ. 4.1.13.9. Нарушение условий настоящего раздела ТЗ, в том числе отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.1.13.10. В случае, если в соответствии с пунктом 4.1.13.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.1.13.11. В случае, если при выполнении Работ положения пунктов 4.1.13.5-4.1.13.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта и настоящего раздела ТЗ, а также о неприменении при выполнении работ готового ПО (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

4.1.13.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности

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

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

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

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

4.1.14 Требования к численности персонала оператора Системы - Дополнительные требования к численности персонала оператора не предъявляются - - Значение характеристики не может изменяться участником закупки

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

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

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

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

4.2 Требования к содержанию работ 4.2.1 Архитектурное решение - 4.2.1 Архитектурное решение Разрабатываемый функционал должен обеспечивать работу двух контуров, предоставляющих различную функциональность. Разделение контуров применяется для: – обеспечения разделения ролевой модели; – обеспечения безопасности данных; – расширения возможностей масштабирования ПО. При проектировании архитектурных решений в рамках импортозамещения и развития П-МКП, необходимо руководствоваться требованиями постановления Правительства РФ от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» и постановления Правительства РФ от 16.11.2015 № 1236 - - Значение характеристики не может изменяться участником закупки

4.2.1.1 Структура информационно-аналитического контура Информационно-аналитический контур, используемый для аналитики и контроля, состоит из следующих функциональных блоков: – АРМ Сотрудника; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок отчетности; – функциональный блок загрузки данных. Названия функциональных блоков могут быть изменены по согласованию с Заказчиком

4.2.1.2 Структура функционального контура Функциональный контур, используемый для работы с прикладным функционалом, состоит из следующих функциональных блоков: – АРМ Подрядчика; – АРМ Заказчика; – функциональный блок ЭП; – функциональный блок для формирования аналитики проектов и объектов; – функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России; – функциональный блок отчетности; – функциональный блок подготовки и передачи данных; – функциональный блок «Информация»; – функциональный блок формирования и ведения календарно-сетевого планирования «ГПР»; – функциональный блок для ведения проектно-изыскательских работ «ПИР»; – функциональный блок для ведения сметной документации; – функциональный блок для формирования и ведения исполнительной документации; – функциональный блок ведения строительного контроля; – функциональный блок ведения договоров «Управление проектом»; – функциональный блок для просмотра и работы с BIM-моделированием; – функциональный блок для ведения электронного документооборота; – функциональный блок для формирования и реализации задач. Для передачи данных из функционального контура в информационно-аналитический контур применяется сервис передачи агрегированных данных. Названия функциональных блоков могут быть изменены по согласованию с заказчиком. Источниками данных для функциональных блоков информационно-аналитического контура являются: – агрегированные данные функционального контура; – загруженные данные из отчетов установленной формы; – данные, введенные вручную в информационно-аналитический контур.

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

4.2.2.2 Расчет типовых аппаратных конфигураций В составе паспорта информационной системы должен быть предоставлен масштабируемый расчет типовых аппаратных конфигураций. Базовый блок: расчет должен быть выполнен для базового блока мощности, рассчитанного на одновременную работу до 1 000 (тысячи) активных пользователей в контуре функционального уровня. Шаг масштабирования: аппаратная конфигурация должна быть тиражируемой. Шагом масштабирования системы является добавление одного базового блока мощности на каждые последующие 500 пользователей. Состав расчета: для каждого базового блока должны быть определены требования к: – количеству и вычислительной мощности (vCPU, RAM) виртуальных или физических серверов для каждого типа сервисов (веб-серверы, серверы приложений, серверы кэширования); – пропускной способности сетевых интерфейсов; – производительности (IOPS, latency) и объему дисковой подсистемы для БД и файловых хранилищ

4.2.2.3 Требования к балансировке нагрузки Балансировка нагрузки осуществляется путем применения нескольких уровней кластеризации нагрузки: – выделение экземпляров приложения под пользователя исходя из стратегии административного, функционального или географического разделения пользователей, и фиксации этого деления отдельными доменами в конфигурации приложения; – использование программного балансировщика нагрузки (Load Balancer) на основе веб-сервера nginx, применяющего стратегию sticky-sessions или ip-hash в рамках одного домена; – возможное применение аппаратных балансировщиков в рамках одного домена. В рамках одного домена экземпляры приложения являются взаимозаменяемыми со встроенными методами балансировщика нагрузки, либо другими решениями, которые осуществляют: – мониторинг здоровья (health checks) экземпляров и автоматическое исключение неработающих узлов из ротации; – возможность бесшовного (без простоя) добавления новых и изъятия существующих экземпляров сервисов

4.2.3 Требования к функциональным блокам информационно-аналитического контура - Виджет «Риски. Параметры» должен отображать объекты под риском (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3х месяцев) и иметь фильтрацию по выпадающему списку с параметрами. Таким образом виджет должен отображать общий план по показателю (в соответствии с данными таблицы «Показатели проекта») на год и долю объекта\объектов под риском в данном плане. Необходимо реализовать виджеты для визуализации отчета «План-график мероприятий». Для отображения сводной информации по реализации проектов должны быть представлены следующие группы виджетов: общая информация об объекте, ход реализации (сроки), финансирование (план), контрактация, обеспеченность машинами и механизмами, стройготовность, привлечение трудовых ресурсов, риски и принимаемые меры. Виджет «Показатели» должен отображать показатели по объекту и по направлениям. В виджете должно быть два основных показателя «Провозная способность, млн. в год» и «Пропускная способность, пар поездом в сутки», которые должны фильтроваться по годам и отображать план и факт по показателям. Виджет «Максимальная весовая норма поездов, тонн» должен отображать план и факт по объекту и по показателю «Максимальная весовая норма поездов» с фильтрацией по объектам. Виджет «Общая информация по объекту» должен отображать полное наименование объекта, код объекта, ответственного Подрядчика/Заказчика, субъект РФ/ фактическое местоположение объекта, назначение объекта, основные характеристики объекта (ТЭП), предварительную стоимость по ФП (млн. руб.). Виджет «Риски. Примечания» должен отображать объекты под риском реализации (зеленый – если рисков нет или они умеренные, желтый – если отставание менее 3-х месяцев и красный – если отставание более 3-х месяцев) с выводом строк «Примечание» и «Необходимые/ принимаемые меры, сроки их реализации». - - Значение характеристики не может изменяться участником закупки

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

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

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

4.2.3.3 Функциональный блок отчетности Функциональный блок отчетности должен обеспечивать поддержку процедур сбора отчетной информации по проектам, в том числе формирование регламентированных периодических отчетов о состоянии реализации проектов, достижении ключевых показателей. Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

В функциональном блоке нужно разработать вкладку со списком загруженных ранее отчетов, c возможностью ознакомиться с основной информацией по ним (дата, время, автор загрузки) и выгрузить в формате xlsx. Необходимо предоставить возможность удаления отчетов с возвращением состояния данных, используемых для показа аналитических панелей, к состоянию прошлого отчета. Должна быть предусмотрена возможность сравнения отчетов, загруженных в разное время, между собой с целью обнаружения несоответствия плановых показателей или ранее введенных показателей прошлых периодов. Для выполнения сравнения требуется разработать интерфейс в функциональном блоке загрузки данных, позволяющий выбрать отчеты для сравнения с ранее загруженными. Результатом сравнения является табличное отображение двух отчетов с цветовой индикацией расхождений в плановых показателях и общих показателях предыдущих периодов. Доступ к загрузке отчетов, их просмотру, сравнению или удалению должен регулировать настройкой прав пользователей, согласно ролевой модели. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

4.2.3.2 Функциональный блок для формирования аналитики проектов и объектов Функциональный блок должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели – дашборд (dashboard). Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда. Данные для формирования виджетов вносятся из отчета «План-график мероприятий» (описание состава данных указано в приложении № А) или вносятся пользователями и хранятся в соответствующих справочниках. Описание работы функционального блока отчетности представлено в п. 4.2.3.3. Для формирования дашбордов и виджетов необходимо использовать ПО Информационно-аналитическая система «Планета. Аналитика» 3.0», входящее в состав ПО функционирующего в АСУ ТК. В рамках функционального блока для формирования аналитики, паспортизации проектов и объектов требуется реализовать возможность представления аналитических данных с использованием набора данных из карточек (паспортов) инвестиционно-строительных объектов и преднастроенных графических инструментов (географическая карта). Необходимо реализовать графическое отображение совокупности объектов на географической карте с учетом выбранного набора фильтров с возможностью просмотра общей информации по каждому из объектов. Панель (виджет) интерактивной схемы должна распределяться на следующие вкладки: – таблица (перечень объектов); – схема (интерактивная схема субъектов РФ с обозначением количества объектов); – карта (интегрированная картографическая карта)

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

4.2.4 Функциональные требования к блокам функционального контура - 4.2.4.1 АРМ Подрядчика АРМ Подрядчика предназначен для выполнения подрядчиком операций по взаимодействию с Заказчиком, таких как: – загрузка документов, связанных с реализацией проектов, из файлов в формате XML; – согласование документов с Заказчиком; – подписание документов со стороны Подрядчика и Заказчика; – получение замечаний по документам; – управление доступом пользователей, являющимися представителями Подрядчика, как к АРМ Подрядчика, так и к конкретному объекту. Функциональный блок должен позволять Подрядчику вносить объем данных, связанных с реализацией проекта, достаточный для формирования сводных (агрегированных) данных. - - Значение характеристики не может изменяться участником закупки

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

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

4.2.4.6 Функциональный блок отчетности Необходимо разработать следующий функционал: – формирование отчетных форм путем выбора стандартных преднастроенных информационных блоков; – автоматическое и ручное заполнение форм блоков; – функционал сохранения отчетных форм в виде шаблонов для их применения в различных объектах; – формирование печатных форм отчетов; – отображение всех загруженных прикрепленных файлов в качестве приложений к отчетам; Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.12 Функциональный блок для формирования и ведения исполнительной документации Необходимо разработать следующий функционал: – формирование, согласование и подписание ЭП исполнительной и закрывающей документации в электронном формате; – формирование КС-2, КС-3, КС-6а; – выгрузка печатных форм актов ИД в соответствии с актуальной НТД в форматах .pdf, .xlsx, .doc; – формирование реестров документов и материалов для АОСР, АООК, АОУСИТО в соответствии с требованиями Приказа Минстроя России от 16.05.2023 №344/пр; – выгрузка актов ИД архивом; – формирование замечаний к исполнительной документации; – автоматическое формирование реестра исполнительной документации; – простановка штампов на прикрепленные к актам ИД документы; – формирование категорий ИД; – формирование версионности документов; – загрузка новой версии прикрепленного к акту ИД файла; – увязка позиций (в т.ч. нескольких) графика производства работ с актами исполнительной документации; – формирование отчетов по документации (в т.ч. отчет по наличию ИД по объектам строительства); – функционал работы с версионностью документов исполнительной документации; – ручное и автоматическое заполнение реквизитов юридических и физических лиц журналов; – ведение всех разделов общего журнала работ в соответствии с действующим приказом Минстроя России от 02.12.2022 № 1026; – ведение журнала авторского надзора и специальных журналов работ в электронном виде; – автоматическое добавление записей замечаний в журнал авторского надзора выставленных к проектной рабочей/исполнительной документации представителем авторского надзора; – внесение в журналы первичных сведений и актуализация указанной информации (редактирование/ дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – механизм загрузки файлов в записи журнала. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.12.1. Требования к формированию журналов В функциональном блоке для формирования и ведения исполнительной документации должна быть реализована вкладка «Журналы», предоставляющая возможность вести следующие типы журналов: – Общий журнал работ (РД 11-05-2007); – Журнал бетонных работ; – Журнал авторского надзора; – Журнал сварочных работ; – Журнал антикоррозионной защиты сварных соединений; – Журнал входного учета и контроля качества получаемых деталей, материалов, конструкций и оборудования; – Журнал строительного контроля; – Оперативный журнал геодезических работ; – Журнал работ по монтажу строительных конструкций; – Журнал ухода за бетоном; – Журнал прокладки кабеля; – Журнал технического нивелирования; – Журнал регистрации вводного инструктажа по охране труда; – Журнал регистрации вводного инструктажа по пожарной безопасности; – Журнал регистрации инструктажа по пожарной безопасности; – Общий журнал работ (1026/пр). Требования к вкладке «Журналы» представлены в таблице 10. Таблица 10 – Требования к вкладке «Журналы» № п/п Функциональность вкладок 1 Реквизиты для печатной формы журналов 2 Должны отображаться разделы журналов 3 Должна быть возможность добавления замечаний по ведению журналов

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

Необходимо предоставить представителям Подрядчика возможность загружать документы для согласования и подписания с Заказчиком. Документы для подписания должны загружаться в формате xml и соответствовать схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов: – исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/);

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

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

4.2.4.3 Функциональный блок ЭП Для работы с системой электронного документооборота П-МКП необходим сертификат электронной подписи (далее – ЭП) - электронный документ, который подтверждает связь электронной подписи с ее владельцем и используется для проверки подлинности электронных документов и подписей. В соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ (ред. от 28.12.2024) «Об электронной подписи» информация в электронной форме, подписанная квалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством Российской Федерации. После подключения функционального блока ЭП к П-МКП в карточке документа должна появляться возможность электронного подписания. Список документов, которые подписываются с помощью ЭП в П-МКП: – загружаемые документы в формате xml, перечисленные в п. 4.2.4.5; – документы ПИР, ДПТ; – документы, которые будут формироваться в П-МКП: 1) из функционального блока: «Исполнительная документация»; 2) из функционального блока: «Сметная документация»; – бухгалтерские документы; – технические документы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.7 Функциональный блок подготовки и передачи данных Информационно-аналитический контур использует полученную в агрегированном виде информацию для отображения аналитических панелей и формирования отчетности. Первоначальное наполнение информационно-аналитического контура данными происходит при развертывании АРМ. Дальнейшая актуализация информации происходит путем синхронизации данных в автоматизированном режиме не реже 2 раз в сутки. К синхронизации принимаются только те данные, которые непосредственно участвуют в работе контура. Архитектура функционального блока реализует архитектурный стиль REST API и предполагает наличие нескольких уровней: – уровень сетевого взаимодействия; – уровень протокола; – прикладной уровень. Обязательным требованием является расширяемость и конфигурируемость функционального блока. Архитектурное решение с помощью встроенных инструментов и без изменения исходного кода должно обеспечивать: – управление подключениями клиентов - получателей данных и источников данных; – авторизацию клиентов; – валидацию данных при приеме; – возможность настраиваемой фильтрации данных в зависимости от клиента; – настройку стратегии разрешения конфликтов данных; – управление составом передаваемых данных, атрибутивным составом и режимами передачи данных

К функциональному блоку применяются требования отказоустойчивости, регулярности передачи данных и восстановления после сбоев синхронизации, обеспечивающие использование контура информационно-аналитического уровня в соответствии с требованиями данного ТЗ. В процессе формирования частных ТЗ на разработку функционального блока должны быть раскрыты: – список справочников и документов, участвующих в обмене; – атрибутивный состав передаваемых данных; – частота синхронизации и процедуры корректировки данных; – статусная модель для передачи основных справочников и документов; – формат передачи данных; – протокол передачи; – конкретные конфигурации эндпоинтов для осуществления передачи данных. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

– возможность импорта графика с полной заменой списка работ *.xlsx (шаблон MS Excel), *.xer (Primavera), *.xml (MS Project), *.xml (Spider Project); – ручное занесение и последующее редактирование в графике физических показателей (в т.ч. объемов исполнения); – возможность привязки исполнительной документации, закрывающих документов (акты закрытия ПИР и КС-2), технических документов к конкретным работам в ГПР; – возможность непосредственно из ГПР инициировать процедуру формирования исполнительной документации по отдельной работе, указанной в графике; – возможность группировки позиций ГПР по ряду показателей; – возможность фильтрации позиций ГПР по ряду показателей; – возможность отслеживания статусов выполнения работ в контексте объемов и сроков выполнения; – возможность автоматического заполнения ресурсов согласно прикрепленной сметной позиции; – возможность ввода фактически выполненного объема работ в виде суточного графика (посуточный ввод); – формирование графика проведения земельно-кадастровых работ с возможностью вывода статусов (объем и сроки)

4.2.4.4.3.1. Виджеты по тематике «Контроль контрактации и финансирования» Данная группа виджетов должна отображать следующую аналитическую информацию: – Виджет «Лимит законтрактован». Данный виджет должен отображать фактические платежи во всем контрактам и запланированные платежи по всем подписанным контрактам; – Виджет «Лимит не законтрактован» должен отображать разницу суммы финансирования и законтрактованного лимита; – Виджет «Общий план финансирования, доведено» должен представлять сводную информацию по доведенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.). Также в виджете должна отображаться сводная бюджетная роспись по всем видам бюджетов; – Виджет «Общий план финансирования, выделено» должен представлять сводную информацию по выделенному финансированию по всем объектам по годам с разделением по: 1) федеральному бюджету; 2) бюджету субъекта; 3) ФНБ; 4) внебюджетному финансированию (ОАО «РЖД» и т.п.); – Виджет «Отклонение оплат по контрактам» должен отображать общую сумму плановых и фактических платежей по всем подписанным контрактам на текущий дату, а также разницу между этими суммами; – Виджет «Освоение денежных средств» должен отображать сумму денежных средств, сумму фактических и плановых платежей по контрактам; – Виджет «Освоено по контрактам, СМР» должен отображать общую сумму плановых платежей по подписанным контрактам стадии СМР согласно ГПР и общую сумму за выполненные работы, подтвержденные актами КС-2, а также остаток — разницу между этими двумя суммами; – Виджет «Мониторинг банковских гарантий» должен отображать информацию с количеством договоров с действующей, с риском и просроченной банковской гарантией

4.2.4.4.3.2. Виджеты по тематике «Мониторинг выполнения работ и Строительный контроль» Данная группа виджетов отображает следующую аналитическую информацию: – Виджет «Аналитика ГПР по СМР» должен отображать, согласно актуальному ГПР для стадии СМР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами; 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами; – Виджет «Аналитика ГПР по ПИР» должен отображать, согласно актуальному ГПР, для стадии ПИР, следующие сведения: 1) стоимость плановых работ; 2) стоимость фактически выполненных работ; 3) отклонение от плановых показателей общей стоимости фактически выполненных работ; 4) общую стоимость фактически выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР); 5) отклонение от плановых показателей общей стоимости выполненных работ, подтвержденных закрывающими документами (акт закрытия ПИР);

4.2.4.9.1. Требования к возможностям мониторинга графиков Необходимо разработать следующий функционал: – возможность автоматического формирования S-кривой реализации проекта на основании фактически выполненных работ в разрезе стоимостей или объемов работ; – автоматический расчет основных показателей по методу освоенного объема; – возможность формирования задач во встроенном задачнике на основании записей ГПР с автоматическим заполнением основных параметров в карточке задачи; – возможность выгрузки плана освоения в формате Excel; – возможность выгрузки ГПР в формате Excel; – возможность выгрузки ГПР в формате PDF с возможностью настройки колонтитулов; – отслеживание фактического освоения физических и денежных объемов работ по графикам (выполнение в срок по графикам) с отображением соответствующей аналитической информации на виджетах дашборда. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

4.2.4.4 Функциональный блок для формирования аналитики проектов и объектов 4.2.4.4.1. Требования к формированию аналитических панелей Функционал должен включать компонент представления данных, реализованный на «тонком клиенте», для подготовки и отображения визуальных представлений показателей и данных (интерактивные графики, диаграммы, и т. д.). Функционал должен предоставлять возможность настройки индивидуального рабочего стола в виде аналитической панели (далее – дашборд, dashboard), обеспечивающего: – сбор информационно-аналитической панели в виде различных виджетов; – автоматическое обновление информационно-аналитической панели при поступлении новых данных; – фильтрацию данных как в целом по всей информационно-аналитической панели, так и в каждом отдельном виджете. Рабочая область должна быть предназначена для формирования внешнего вида дашборда, а именно для настройки произвольного расположения виджетов в режиме drag-n-drop. Также должен быть реализован реестр, содержащий список всех виджетов с возможностью скрытия отображения на дашборде. В правой части дашборда должно быть расположено меню фильтрации дашборда (по наименованию объектов, типам объектов, проектам и т.д.). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

4.2.4.15 Функциональный блок для просмотра и работы с BIM-моделированием Функциональный блок должен иметь возможность загрузки и просмотра BIM-моделей. Файл модели должен подгружаться в формате .ifc. В функциональном блоке должны быть реализованы следующие функции: – хранение всех версий модели в централизованном репозитории; – загрузка версий моделей; – настройка уровней доступа к моделям; – создание и просмотр атрибутов элементов модели; – перемещение элементов модели; – прикрепление файлов к элементам модели; – интерактивный 3D-просмотр с инструментами навигации; – возможность изменения режима отображения; – возможность изменения видовых экранов; – возможность простановки произвольных разрезов на модели; – детальная информация о каждом элементе модели (атрибуты); – возможность указания размеров; – связывание элементов модели с проектной документацией; – связывание элементов модели с исполнительной документацией; – связывание элементов модели с графиком производства работ; – связывание элементов модели с нарушениями строительного контроля. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

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

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

4.2.4.4.3.4. Виджеты внутри объекта – Виджет «Выполнение по графикам» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ «ГПР»; – Виджет «Освоение по графикам ПИР» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии ПИР; – Виджет «Освоение по графикам СМР (КС-2)» должен отображать стоимость запланированных и фактически выполненных работ по графикам производства работ стадии СМР; – Виджет «Оплачено по контрактам» должен отображать сводную информацию о платежах по подписанным контрактам

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

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

4.2.4.4.3.6. Виджеты по тематике «Расчет экономических показателей эффективности реализации проектов по одному объекту» На сводном дашборде необходимо отобразить базовые финансовые показатели по одному конкретному объекту. В верхней части дашборда отображаются строки: – «Подрядчик по СМР»; – «Контракт на СМР»; – «Подрядчик по АН»; – «Подрядчик по СК»; – заполненные в соответствии с информацией, указанной в Контрактах. Необходимо отобразить следующую информацию по объекту: – федеральный округ; – cубъект РФ; – стоимость объекта (стоимость по сводному сметному расчету); – сроки реализации; – строительная готовность; – ЛБО на текущий год (лимиты бюджетных обязательств, поступающие на расчетный счет организации через расходное расписание из казначейства и используемые для оплаты Контрактов); – касса в текущем году; – цена контрактов; – всего оплачено; – выплачено аванса (сумма, перечисляемая Подрядчику на его казначейский счет по условиям Контракта); – дебиторская задолженность; – закрыто работ; – закрыто работ в текущем году; – незаконтрактованный объем в текущем году (источником данных является выписка с лицевого счета из казначейства, в которой отражены доведенные лимиты и принятые обязательства по контрактам. Показатель рассчитывается как разница между лимитами и обязательствами. Результат может быть отрицательным при переконтрактации)

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

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

– формирование автоматических уведомлений вовлеченным в процесс согласований пользователям об устранении замечаний, включая автоматическую отправку уведомления в адрес лица, сформировавшего замечание к документу; – процедура работы автора замечания с устраненными исполнителем замечаниями – наличие функций «Принять» и «Ответ на замечания»; – отображение количества активных замечаний, находящихся в работе для каждого размещенного документа ПИР; – формирование и ведение реестров замечаний к документации; – сравнение документов ПИР, ДПТ в формате *.pdf путем наложения; – простановка штампов на документы проектной и рабочей документации с возможностью выбора: «Копия верна», «Проект согласован», «В производство работ», «Выполнено в соответствии с проектом». Должна быть реализована возможность корректировки расположения штампа на листе документации. Возможность простановки нескольких штампов. Возможность замены или удаления ранее установленного штампа при необходимости; – функция проставления QR-кода на документ ПИР, ДПТ с целью открытия документа, ознакомления с ним, просмотра его статуса, выявления актуальности и этапа разработки. Должна быть реализована возможность корректировки расположения QR-кода на листе документации и указание листов для простановки QR-кода; – хранение и отображение истории изменения замечаний, корректировок, согласований и подписаний по каждому документу ПИР, ДПТ; – хранение и отображение версии по каждому документу ПИР с указанием актуальной версии; – формирование аналитической информации для документов ПИР, ДПТ по распределению количества документов по статусам, по типам документов, по статусам согласований, по наличию активных/отработанных замечаний, по авторам и ответственным лицам; – формирование Акта приема-передачи документации ПИР, ДПТ; – формирование данных в формате, предусмотренном ФАУ «ГГЭ» для последующей загрузки документации на портал для проведения Государственной экспертизы;

– процедура контроля проведения Государственной экспертизы, контроль сроков проведения экспертизы, контроль прохождения этапов экспертизы, контроль устранения замечаний. Требования к вкладкам функционального блока «ПИР» представлены в таблице 8. Таблица 8 – Требования к вкладкам функционального блока «ПИР» № п/п Функциональность вкладок 1 Должна иметь функционал для создания и работы с документами инженерных изысканий. 2 Должна иметь функционал для создания и работы с документами проектирования. 3 Должна иметь функционал для создания документов, которые могут быть использованы повторно. 4 Должна иметь функционал для создания и работы с различными документами. 5 Должна осуществляться работа с реестрами проектной и рабочей документации. 6 Должна иметь функционал для создания и работы с актами закрытия ПИР. 7 Должны быть размещены виджеты, характеризующие процесс работыс документацией ПИР. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.5 Функциональный блок загрузки данных из файлов формата XML для передачи строительных документов по утвержденным схемам Минстроя России Функциональный блок загрузки данных из файлов предназначен для работы Подрядчиков в контуре функционального уровня. Он должен обеспечивать пользователям, выступающим представителями Заказчика, возможность загрузки проектной и исполнительной документации по объекту строительства в формате XML, утвержденной Минстроем России для передачи и подписания документов в электронном виде. Интерфейс для осуществления загрузки данных из файлов формата XML должен располагаться в АРМ Подрядчика. Функциональный блок должен поддерживать загрузку файлов документов в формате xml , соответствующих схемам, опубликованным на официальном сайте Минстроя России. Минимальный перечень документов:

– исполнительная документация: 1) Акт разбивки осей объекта капитального строительства на местности (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-razbivki-osey-obekta-kapitalnogo-stroitelstva-na-mestnosti/c7_3/); 2) Акт освидетельствования участков сетей инженерно-технического обеспечения (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-uchastkov-setey-inzhenerno-tekhnicheskogo-obespecheniya/c6_3/); 3) Акт освидетельствования скрытых работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-skrytykh-rabot/c5_3/); 4) Акт освидетельствования ответственных конструкций (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-otvetstvennykh-konstruktsiy/c4_3/); 5) Акт освидетельствования геодезической разбивочной основы объекта капитального строительства (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-osvidetelstvovaniya-geodezicheskoy-razbivochnoy-osnovy-obekta-kapitalnogo-stroitelstva/c3_3/); 6) Акт о выявленных дефектах приборов, оборудования и агрегатов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-vyyavlennykh-defektakh-priborov-oborudovaniya-i-agregatov/c55_1/); 7) Акт испытания гидропневматической емкости (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-gidropnevmaticheskoy-emkosti/c54_1/); 9) Акт испытания внутреннего противопожарного водопровода (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-ispytaniya-vnutrennego-protivopozharnogo-vodoprovoda/c56_1/); 10) Акт о проведении входного контроля (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-o-provedenii-vkhodnogo-kontrolya/c57_1/);

– журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/);

– строительный контроль: 1) Протокол осмотра (https://www.minstroyrf.gov.ru/tim/xml-skhemy/protokol-osmotra/c27_2/); 2) Акт по результатам контрольного (надзорного) без взаимодействия с контролируемым лицом (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-po-rezultatam-kontrolnogo-nadzornogo-meropriyatiya-bez-vzaimodeystviya-s-kontroliruemym-litsom/c36_1/); 3) Решение органа по ходатайству о продлении срока исполнения предписания об устранении нарушений при строительстве, реконструкции объекта капитального строительства (о восстановлении сроков подачи жалобы на решение контрольного (надзорного) органа) (https://www.minstroyrf.gov.ru/tim/xml-skhemy/reshenie-organa-po-khodataystvu-o-prodlenii-sroka-ispolneniya-predpisaniya-ob-ustranenii-narusheniy-/c47_1/); 4) Акт документарной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-dokumentarnoy-vneplanovoy-proverki/c2_3/); 5) Акт выездной внеплановой проверки (https://www.minstroyrf.gov.ru/tim/xml-skhemy/akt-vyezdnoy-vneplanovoy-proverki/c1_3/); 6) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_4/); 7) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/); 9) Решение о проведении контрольного (надзорного) мероприятия (https://www.minstroyrf. gov.ru/tim/xml-skhemy/reshenie-o-provedenii-kontrolnogo-nadzornogo-meropriyatiya/c17_3/)

4.2.4.11 Функциональный блок для ведения сметной документации Необходимо разработать следующий функционал: – загрузка смет в исходных форматах (gsfx, gge и xml (ГрандСмета); – загрузка расчетов по шаблону xlsx; – загрузка смет с учетом индексов и использованной методики расчета (35МДС, Методика 2020 по 421пр, по 557пр); – загрузка платежных поручений; – загрузка сметы с учетом индексов и использованной методики расчета; – распознавание расчеты, составленные базисно-индексным методом, ресурсно-индексным или ресурсным методом; – возможность создания редактирования, удаления дополнительных затрат, настройка параметров и способов начисления; – автоматизированная работа с дополнительными затратами; – загрузка сметы по отношению к исходной смете, c последующим использованием в графике производства работ процедуры планирования и учета выполненных работ по смете; – инструментарий для сравнения смет возможность сравнения двух расчетов. Подсветка изменений: увеличение/уменьшение стоимости, объемов. Экспорт результатов в Excel; – возможность редактирования и удаления позиций сметы вручную; – формирование сметы контракта на основании загруженных локальных сметных расчетов, а также импорт сметы контракта в форматах gsfx и xml (ГрандСмета); – возможность редактировать точность округления дополнительных затрат; – передача плановой информации по сметным ресурсам, сметной стоимости, сметным трудозатратам и физическим объемам работ из локальных смет в ГПР; – централизованное хранение и структуризация по главам сводного сметного расчета смет в единой веб-платформе; – реализация процедуры формирования и отслеживания изменений, вносимых в смету контракта, с учетом внесения изменений в сметные расчеты, формирующие позиции сметы контракта

Требования к вкладкам функционального блока «Сметы» представлены в таблице 9. Таблица 9 – Требования к вкладкам функционального блока «Сметы» № п/п Функциональность вкладок 1 Должна быть реализована возможность загрузки смет формата gsfx/xml или gge, шаблона xls или xlsx. 2 Должна быть реализована возможность сравнения двух смет (например, исходную и корректировочную). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

Таблица 5 – Вкладки функционального блока «Информация» 1 Должна содержать общую информацию по объекту и график реализации. Общая информация должна собираться из сведений, внесенных в карточку объекта. 2 Должна отображать показатели, связанные с объектом. Часть информации должна вводится вручную, часть заполняется автоматически. 3 Должны отображаться физические и юридические лица, связанные с данным объектом. При заполнении ИНН участника, данные по юридическому лицу должны заполняться автоматически (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика). Добавление нового участника в карточку объекта должно происходить через присвоение роли, правильное заполнение данной вкладки позволит в дальнейшем автоматически заполнять документацию по объекту. 4 Должна позволять сохранять все загруженные файлы. Предоставить возможность загружать файлы непосредственно в файловое хранилище и затем выбирать их для прикрепления в ряде записей других справочников, связанных с объектом. 5 Должна предоставлять информацию по финансированию проекта в зависимости от источника финансирования и времени. Информация на вкладке формируется вручную. Данные должны сводиться в виде виджета на странице, а также могут выгружаться в электронную таблицу с возможностью фильтрации. 6 Должна отображать информацию по процессам, связанным с земельным участками и объектом строительства. 7 Должна отражать фотографическую информацию по объекту. Для отображения изображения во вкладке необходимо предварительно загружать его в раздел «Фотогалерея» блока «Файловое хранилище». 8 Должна отражать информацию, поступающую с установленных камер видеонаблюдения на объекте строительства. 9 Должна представлять перечень проблемных вопросов, связанных с объектом строительства. Информация должна вводиться вручную. 10 Должна представлять задачи, связанных с объектом строительства. 11 Должна содержать возможность по форм. писем и отправкой пользователем с возможностью уведом

Функциональный блок «Информация» должен обеспечивать выполнение следующих функций: – отображение объекта на интерактивной Яндекс карте (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика); – просмотр истории загрузки файлов; – визуальное отображение графика реализации объекта по датам, в соответствии со сформированными графиками стадии СМР и ПИР по заключенным контрактам; – ведение учета и заполнение всех показателей объекта (ТЭП, данные ГГЭ, градостроительных, капитальных затрат и др.); – ввод и добавление юридических лиц и физических лиц, являющихся участниками реализации объекта строительства, с указанием наименований, ФИО, ролей и должностей ответственных лиц, контактных данных и приказов; – добавление, хранение, выгрузка и структуризация файлов, выполненных на сторонних программных комплексах (в форматах XML, PDF, TIF и JPG в отношении каждого объекта); – ручной импорт и учет данных о выделенном и доведенном финансировании инвестиционно-строительного проекта с указанием и распределением объемов по источникам финансирования (включая финансирование из бюджетов разных уровней) и за различные периоды; – формирование данных о выделенном земельном участке для объекта строительства и направленных Технических условиях; – формирование и отображение фотогалереи объекта, со следующим функционалом: 1) возможность создания фотоотчета с привязкой к дате; 2) возможность удаления фотоотчета со всем содержимым; 3) одновременное прикрепление нескольких файлов; 4) фильтрация по дате создания фотоотчета; 5) приложение и удаление фотографий; 6) указание даты фотоотчета, названия и комментария; 7) просмотр фотографий в PNG, JPG, JPEG, перелистывание фотографий;

– просмотр данных с камер видеонаблюдения, размещенных на площадке строительства в режиме реального времени (при согласовании доступа к ресурсу со стороны Подразделения информационной безопасности Клиента Заказчика) со следующим функционалом: 1) добавление и удаление камер; 2) указание наименования, ссылки на видеопоток, адреса расположения камеры; – ведение учета вопросов, возникающих в период выполнения инвестиционно-строительного проекта с указанием предпринятых мер, дат и привязкой к ответственным исполнителям; – создание и контроль задач в привязке к отдельным работам, возникающим в период выполнения проекта, с указанием плановых и фактических дат выполнения, ответственных исполнителей, наблюдателей и контролеров, приоритетов, текущих статусов и взаимосвязей с другими задачами; – формирование деловой переписки между участниками строительства с указанием отправителей, получателей, тематики, статусов, номеров и дат по каждому документу/ письму; – формирование статусной модели, отражающей этап, на котором находится объект в текущий момент; – формирование расписания работ (календарного плана) проекта; – возможность связи проекта с другими объектами (выбор из имеющихся в модуле); – формирование файлового хранилища на основании прикрепленных к карточке объекта документов со следующим функционалом: 1) структурированное представление вложенности файлов по разделам; 2) хранение документации в форматах XML, DOCx, XLS, PDF, PNG, TIF, JPG, GSFX GGE. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.9 Функциональный блок формирования и ведения календарно-сетевого планирования «ГПР» Требования к функциональному блоку «ГПР» представлены в таблице 6. Таблица 6 – Требования к функциональному блоку «ГПР»:

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

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

Функциональные возможности вкладки «Журналы»: – ведение всех разделов общего журнала работ в соответствии с РД-11-05-2007, а также ведения специальных журналов работ в электронном виде; – ведение всех разделов ОЖР, в котором ведется учет выполнения работ по строительству, реконструкции, капитальному ремонту объекта капитального строительства (Приказ Минстроя России от 02.12.2022 N 1026/пр), а также ведение специальных журналов работ в электронном виде; – автоматическое заполнение реквизитов юридических и физических лиц общего журнала работ; – внесение в Журналы первичных сведений, актуализации информации (редактирование/дополнение); – заполнение разделов журнала работ, синхронизация общего журнала работ и журнала входного контроля с исполнительной документацией; – наличие механизма загрузки файлов в записи журнала; – ведение журнала Авторского надзора (СП 246.1325800.2023 Приложение Б); – участие представителей Авторского надзора в проведении (согласовании) проверок и выявлении нарушений; – автоматическое добавление записей замечаний в журнал Авторского надзора, выставленных к проектной рабочей/исполнительной документации представителем Авторского надзора; – загрузка существующих скан-копий Журналов

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

Работа с карточкой документа: – обеспечение жизненного цикла документа (прохождение документа по этапам); – обеспечение ролевой модели пользователей, участвующих в работе с документом: 1) инициатор – пользователь, создавший документ, который управляет запуском и прохождением этапов; 2) администратор организации – пользователь от организации, назначенной на один из этапов, который назначает ответственных сотрудников от своей организации; 3) согласующий – пользователь от организации, который должен согласовать документ в запущенном процессе Согласование. Представление карточки документа: – в виде краткой карточки (запись в списке документов), которая должна содержать краткую информацию о текущем статусах документа с указанием сведений: 1) атрибуты документа (наименование, инициатор, тип документа и др.); 2) кнопка скачивания текущего пакета прикрепленных файлов; 3) цветовая индикация статуса документа в текущем процессе; 4) срок выполнения целевого действия; 5) кнопки быстрого доступа к целевым действиям; – в виде расширенной карточки (открывается при нажатии на краткую карточку), содержащей разделы: 1) текущие файлы – раздел с актуальным набором прикрепленных в карточку документа файлов (загрузка файлов в форматах word, excel, pdf); 2) сведения – раздел, содержащий основную информацию о документе (наименование, тип документа) и журнал действий, отражающий текущий статус прохождения документа по стадиям жизненного цикла; 3) согласование – раздел, содержащий информацию о текущем маршруте согласования, наборе согласуемых файлов, листе согласования и архивных записях предыдущих маршрутов согласования; 4) связи – раздел, содержащий информацию о связях документа с контрольными точками Объектов. Этап «Инициация документа / Создание / Заведение в систему»: – возможность создания документа инициатором из контрольных точек или без привязки к ним – через раздел «АРМ Подрядчика» в ЛК; – инициатору должно быть доступно заполнение всех разделов расширенной карточки документа;

– возможность согласования проекта документа на стороне согласующих организаций: 1) назначение администратором организации ответственных сотрудников – согласующих и утверждающего от организации; 2) возможность рассмотрения документов ответственными сотрудниками путем выбора опций: Согласовать, Отказать или Сменить исполнителя; 3) возможность, в случае постановки согласования, написать комментарий (обязательное поле, в случае отказа), прикрепить файлы; 4) возможность смены согласующего на другого пользователя системы в рамках одной согласующей организации; 5) возможность утверждающему подписать документ своей электронной цифровой подписью (ЭП). Документ должен поступать утверждающему автоматически после получения согласования от всех согласующих лиц в рамках одной согласующей организации; – хранение информации о предыдущих маршрутах согласования; – возможность добавления/замены/удаления сотрудника в запущенном маршруте согласования (доступно, если у такого сотрудника отсутствует согласование и документ не перешел в работу утверждающему). Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

4.2.4.17 Функциональный блок для формирования и реализации задач Требования к разрабатываемому функционалу: – организация списка задач: 1) функциональный блок формирования и реализации задач должен состоять из следующих подразделов: Все, Активные задачи, Выполняю, Контролирую, Наблюдаю, Созданные мной, Неактуальные, Просроченные, Выполненные. Каждый из блоков должен содержать следующую информацию: o наименование задачи; o номер задачи; o статус; o тип задачи; o исполнители, контролеры, наблюдатели; o делегировано; o начало исполнения/срок исполнения/выполнено; o автор; 2) формирование подчиненных задач и чек-листов для проверки исполнения задач; 3) функции фильтрации/ранжирования по указанным параметрам для перечня обрабатываемых задач; 4) функция прикрепления к задаче документа, подтверждающего выполнение рассматриваемой задачи; 5) задачи должны отображаться с учетом разграничения прав доступа к функционалу на основании функции матрицы групп задач; 6) задачи должны отображаться в виде списка/канбан/календаря; – работа с карточкой задачи: 1) карточка задачи должна содержать следующие блоки: o приоритет; o статус задачи; o плановая дата начала/срок исполнения; o сдана на проверку; o выполнена; o участники: ? исполнители; ? наблюдатели; ? контроллеры; ? автор задачи; o комментарии и файлы - возможность просматривать и прикреплять файлы и комментарии (сквозное отображение комментариев и файлов); o история изменений - таблица, в которой фиксируются изменения по задаче (автор изменений, время изменений, исходное/новое значение); o в карточке задачи ответственному сотруднику должно быть доступно: ? заполнение комментариев; ? прикрепление файлов; ? переназначение задачи на другого сотрудника; ? формирование отчета о выполнении задачи

– доступные действия с документом: 1) редактирование карточки документа, в зависимости от настроенной правовой модели 2) отправка в документооборот; 3) удаление карточки документа. Процесс «Согласование»: – возможность согласования проекта документа на стороне инициатора документа: 1) возможность отслеживания процесса согласования проекта документа, изменений статусов рассмотрения каждым из согласующих; 2) возможность добавления участника в запущенный маршрут согласования; 3) возможность удаления участника из запущенного маршрута согласования, если ни один сотрудник организации еще не согласовал документ; 4) возможность снять документ с маршрута согласования; 5) получение уведомлений о согласовании от каждого утверждающего согласующих организаций и о завершении маршрута согласования в целом; 6) возможность формирования и выгрузки листов согласования в формате pdf по всем или отдельно выбранным организациям, от которых получена резолюция (в рамках одного маршрута согласования). Листы согласования должны формироваться на каждую организацию, указанную в маршруте согласования, и должны быть доступны к скачиванию после получения резолюции Утверждающего; 7) возможность загрузки нового пакета файлов в карточку документа, когда текущий маршрут согласования завершен (с возможностью просмотра предыдущих версий документов на завершенных маршрутах согласования), и отправки документа на повторное согласование (создание нового маршрута согласования);

– журналы: 1) Журнал бетонных работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-betonnykh-rabot/c58_1/); 2) Журнал авторского надзора (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-avtorskogo-nadzora/c59_1/); 3) Общий журнал работ (https://www.minstroyrf.gov.ru/tim/xml-skhemy/obshchiy-zhurnal-rabot/c13_3/); 4) Журнал входного контроля материалов (https://www.minstroyrf.gov.ru/tim/xml-skhemy/zhurnal-vkhodnogo-kontrolya-materialov/c8_3/); – строительный контроль: 1) Предписание об устранении выявленных нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/predpisanie-ob-ustranenii-vyyavlennykh-narusheniy/c14_3/); 2) Извещение об устранении нарушений (https://www.minstroyrf.gov.ru/tim/xml-skhemy/izveshchenie-ob-ustranenii-narusheniy/c19_2/). Доступ пользователей к АРМ Подрядчика регулируется настройками прав пользователя. Доступ должен выдаваться как на все вкладки АРМ Подрядчика, так и на выбранный перечень вкладок. Видимость объектов строительства определяется выданным администратором от Подрядчика или от Заказчика доступом. Показ отдельных видов документов должен определяться настройкой прав роли пользователя и задается администратором П-МКП. Подключение Подрядчика к новому АРМ Подрядчика выполняется через АРМ Заказчика. АРМ Подрядчика должен иметь возможность блокировки по решению Заказчика. В таком случае всем пользователям АРМ Подрядчика должен быть прекращен доступ к объектам строительства и интерфейсу функционального блока. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

№ п/п Функциональность вкладок 1 Должна быть реализована возможность просмотра сводной верхнеуровневой информации о всех стадиях строительства и всех версиях ГПР по объекту. Возможность создания новой версии ГПР для определенной стадии. 2 Отображение детальной информации по ГПР должно иметь возможность производить основную работу с ними: – создавать и редактировать ГПР; – импортировать/экспортировать ГПР из других программных комплексов (MS Project, Primavera P6, Spider Project); – возможность просмотра и редактирования иерархической структуры работ (ИСР/WBS); – внесение информации о плановых и фактических сроках выполнения работ; – формирование зависимости на интерактивной диаграмме Ганта; – выполнение привязки сметных позиций к позициям ГПР; – проведение план-фактного анализа выполнения работ; – отслеживание и формирование взаимосвязи с исполнительной документацией и закрывающими документами, документами ПИР и недостатками; – делегирование графика или часть графика. 3 Визуальный инструмент управления проектом должен позволять оценить прогресс выполнения работ, стоимость во времени на основании графика в формате S-кривой проекта. Должны рассчитываться показатели для оценки состояния проекта по методу освоенного объема. 4 Должна позволять работать с версиями ГПР: – добавлять новые версии; – редактировать или удалять существующие; – просматривать информацию о конкретной версии. 5 Должна позволять работать со стадиями реализации: – добавлять новые стадии; – редактировать или удалять существующие; – просматривать информацию о конкретной стадии

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

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

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

4.2.5 Общие требования к функционированию - 4.2.5.4 Требования к структурированию списков проектов Базовая функциональность имеет возможность структурирования объектов по проектам. Списки проектов включают в себя набор карточек объектов, объединенных по определенным признакам. Раздел управления объектами должен обеспечивать предоставление пользователям АРМ структурированной информации по сгруппированным и структурированным типам объектов, которые ведутся в системе. Раздел должен обеспечивать выполнение следующих функций: – создание проектов и наполнения их Объектами; – возможность прикрепить Объект только к одному проекту; – просмотр списка Объектов, входящих в состав выбранного проекта; – возможность перехода к конкретному Объекту; – сбор аналитической информации по проектам с визуализацией ключевой информации по каждому проекту за текущий год. Каждый пользователь должен видеть статистику по проектам, к которым у него есть доступ - - Значение характеристики не может изменяться участником закупки

4.2.5.5 Требования к системе идентификации и аутентификации (ЕСИА) Процессы идентификации и аутентификации осуществляются с использованием программного обеспечения, являющегося сертифицированным программным средством защиты и обеспечивающего требуемые в п. 4.1.9 уровни информации защищенности. Программное обеспечение должно использоваться для управления содержимым, сервисами, учетными записями пользователей. Для проведения идентификации и аутентификации пользователя следует использовать протокол взаимодействия OpenID Connect 1.0 (OIDC)/OAuth 2.02

4.2.5.1 Требования к ведению справочников и реестров Работы по импортозамещению и развитию П-МКП должны быть выполнены на основе единой системы управления данными, определяющей совокупность классификаторов, справочников, реестров, регистров данных, форматов хранения и интерфейсов обмена данными. Необходимо обеспечить следующие функциональные возможности: – загрузка, обработка, хранение, ввод информации, формирование документов; – централизованное управление информацией (изменение информации); – создание новых сущностей (задач); – атрибутивный и полнотекстовый поиск информации с применением фильтров; – выгрузка ранее внесенных данных в форматах .docx, .csv, .xlsx, .pdf и др.; – система специализированных справочников и классификаторов, предусматривающая управление и присвоение соответствующих атрибутов требуемым сущностям. Функционал должен предоставлять пользователю возможность в ручном режиме вносить, обновлять, удалять данные по ключевым сущностям системы

4.2.5.2 Требования к уведомлениям АРМ должны обеспечивать оперативное оповещение пользователей о произошедших или о приближающихся событиях. В рамках выполнения Работ необходимо реализовать систему уведомлений для получения пользователями системы уведомлений по ключевым событиям: контрольным точкам и задачам любых объектов. Требования к разрабатываемому функционалу: – возможность рассылки почтовых уведомлений и персональной настройки правил рассылки (push и / или e-mail рассылка). Для настройки перечня уведомлений должна быть предусмотрена отдельная страница, где отображаются события и способ получения уведомлений; – просмотр списка уведомлений; – указание в уведомлении: 1) вида уведомления (в заголовке); 2) наименования КТ, плановых дат (начала/окончания), наименования Объекта, наименования результата – для уведомлений по КТ и задачам; – наименование документа, типа документа, статуса и срока согласования / подписания / исполнения, согласования или отказа, даты согласования или отказа и комментария (при наличии) – для уведомления функции согласований; – отправка уведомлений по контрольным точкам и задачам виды уведомлений: 1) о работе с замечаниями; 2) об обновлении задачи; 3) о выполнении задачи; 4) об истекающем времени выполнения задачи (за 3дня до наступления срока); 5) об истекшем времени выполнения задачи; – отправка уведомлений для работы функционала согласований; – настройка уведомлений с помощью бота, внешние рассылки в Мессенджере, согласованном Заказчиком на этапе проектирования; генерация ссылки в email уведомлениях для перехода на страницы системы. Требования к реализации функционального блока должны быть уточнены до окончания этапа № 1 Календарного плана

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

4.3 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу Системы в действие 4.3.1 Общие требования - 4.3.3 Требования к организации ввода данных Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или БД они будут храниться и какими компонентами Системы использоваться. Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления - - Значение характеристики не может изменяться участником закупки

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

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

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

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

5 Состав и содержание работ по развитию АСУ ТК - В соответствии с настоящим ТЗ Подрядчиком должны быть выполнены работы по развитию Системы, включая проектирование, разработку новой функциональности Системы, проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний Системы. В рамках исполнения этапа № 1 Подрядчик должен выполнить Техническое проектирование новой функциональности АСУ ТК. В рамках исполнения этапа № 2 Подрядчик должен выполнить работы по разработке новой функциональности согласно п. 4.2. настоящего ТЗ и проведению предварительных испытаний разработанных функций Системы. В рамках исполнения этапа № 3 Подрядчик должен выполнить работы по проведению опытной эксплуатации в отношении мероприятий, включенных в пилотную зону и приемочных испытаний разработанных функций Системы. Подрядчик выполняет все работы по настоящему ТЗ на тестовых объемах данных, предоставленных Заказчиком. Заказчик самостоятельно обеспечивает проведение мероприятий по информационной безопасности, в том числе аттестацию АСУ ТК на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну. Подрядчик в рамках этапа № 2 должен в срок не позднее 30.04.2026 года передать исходные коды разработанного программного обеспечения. Установка, настройка и пуско-наладка Системы для проведения аттестационных мероприятий выполняет Заказчик с привлечением представителей подрядчика. Ввод в промышленную эксплуатацию, разработанных функций Системы, производится Заказчиком только после проведения аттестационных испытаний Системы (не является частью данного ТЗ) - - Значение характеристики не может изменяться участником закупки

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

3 Опытная эксплуатация и приемочные испытания. 3.1. Опытная эксплуатация. Начало: с 01.05.2026; Окончание: 23.06.2026 Сопроводительным письмом предоставлены Заказчику: Матрица ролей и ответственности; План и программа проведения консультационных мероприятий; Протокол проведения консультационных мероприятий; Документы по испытаниям в составе: - Акты инструментальных проверок в соответствии с разделом 4.1.10 ТЗ; - Отчет о проведении опытной эксплуатации с приложением журнала опытной эксплуатации; - Акт о завершении опытной эксплуатации; - Программа и методика приемочных испытаний; - Результаты проведения нагрузочного тестирования для подтверждения соответствий требований, предъявляемых пунктом 4.1.3 ТЗ Срок согласования Заказчиком документов в рамках настоящего подпункта - не более 5 (пяти) рабочих дней с даты получения Заказчиком документации (должен учитываться Подрядчиком при выполнении работ по этапу). 3.2 Приемочные испытания. Начало: с 24.06.2026; Окончание: 30.06.2026 Сопроводительным письмом предоставлены Заказчику: - Протокол приемочных испытаний; - Исходные коды разработанного (передаваемого) программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Дистрибутив программного обеспечения (с учетом изменений, внесенных по результатам опытной эксплуатации); - Акт о приемке в эксплуатацию (проект); - Документы в соответствии с разделом 4.1.13 Технического задания; - Акты передачи исключительных прав на результаты работ по контракту (на отчетные документы и на разработанное программное обеспечение); - Актуализированная рабочая и техническая документация, переданная Заказчику при исполнении 1-го и 2-го этапов исполнения контракта - если по итогам проведения опытной эксплуатации требуются корректировки в такую документацию; - Обеспечение исполнения гарантийных обязательств; - Документ о приемке по этапу. Начало: с 01.05.2026; Окончание: не позднее 30.06.2026

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

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

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

6 Требования к документированию, порядок контроля и приемки 6.1 Требования к документации - Техническая и эксплуатационная документация на П-МКП (далее - документы на П-МКП) должны удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 59853-2021 в части терминологии; – ГОСТ 34.201-2020 в части наименования и обозначения документов; – ГОСТ 34.602-2020 – в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». Документы на П-МКП должны оформляться в соответствии с требованиями ГОСТ 2.105-2019 на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Комплект эксплуатационной документации на П-МКП должен содержать сведения для эксплуатации П-МКП, а в части ПО должен содержать описание, обеспечивающее ее установку, настройку, эксплуатацию и сопровождение. При разработке документов на П-МКП допускается отклонение от требований комплекса стандартов, описанных выше. Документам на П-МКП должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленным в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой Протокола предварительных испытаний и формой Акта о приемке в опытную эксплуатацию. Документ «Программа и методика опытной эксплуатации» должен включать приложения с формой Акта о завершении опытной эксплуатации и формой Отчета о проведении опытной эксплуатации с приложением журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой Протокола приемочных испытаний и формой Акта о приемке системы в эксплуатацию. Порядок разработки документации по этапам определен в п. 5 ТЗ - - Значение характеристики не может изменяться участником закупки

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

Опытная эксплуатация проводится в пилотной зоне. В рамках опытной эксплуатации должна быть выполнена загрузка данных в отношении мероприятий, включенных в пилотную зону: – реконструкция аэродрома аэропорта г. Горно-Алтайск; – реконструкция и строительство аэропорта Грозный

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

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

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

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

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

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

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

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

7 Источники разработки - Разработка ТЗ производилась с учетом положений следующих нормативно-технических документов: ГОСТ 2.105-2019 «Единая система конструкторской документации. Общие требования к текстовым документам». ГОСТ 34.602-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» - - Значение характеристики не может изменяться участником закупки

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

Профинансировано (оплачено) финансовых средств, млн. руб. Всего нарастающим итогом с начала реализации (до утверждения паспорта ФП) Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего нарастающим итогом после утверждения паспорта ФП Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного периода Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего по контракту/контрактам СМР Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Освоено (принято) (млн. руб.) - до 2018 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 Всего нарастающим итогом с начала реализации (до утв. паспорта ФП) Всего нарастающим итогом после утверждения паспорта ФП Всего с начала отчетного года Всего с начала отчетного месяца Всего по контракту/контрактам СМР - - Плановый объем финансирования по контракту/контрактам СМР, (млн. руб.) Законтрактовано (млн. руб.) Всего нарастающим итогом Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.) Всего с начала отчетного года Всего федеральный бюджет бюджет субъекта РФ ФНБ внебюджет (ОАО «РЖД» и т.п.)

Таблица А.2 – Описание состава загружаемых данных по мероприятиям проекта строительства высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург Наименование показателя Описание показателя Проекты текущего года, млрд. рублей Остаток Выделенный лимит по проектам на текущий год, за вычетом суммы принятого выполнения Факт периода Объем выполнения нарастающим итогом за период формирования данных Проекты текущего года, млрд. рублей в разрезе проектов План года Выделенный лимит по проекту на год План периода Плановые параметры нарастающим итогом за период формирования данных по проекту Факт периода Объем выполнения нарастающим итогом за период формирования данных по проекту Количественное распределение объектов по этапам реализации текущего года, шт. объектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства Количественное распределение объектов по этапам реализации текущего года, шт. объектов, в разрезе проектов Проектирование Количество объектов, находящихся на стадии проектирования Строительство Количество объектов, находящихся на стадии строительства

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

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

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

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

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

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

Размер обеспечения заявки: 2 100 000,00 РОССИЙСКИЙ РУБЛЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документы

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

Документы

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