5 6 7 8 СОДЕРЖАНИЕ 1. ОБЩИЕ СВЕДЕНИЯ ................................................................................................................ 11 1.1 Полное наименование системы и ее условное обозначение: ........................................... 11 1.2 Шифр темы или номер договора ........................................................................................ 11 1.3 Наименование заказчика и разработчика Системы .......................................................... 11 1.4 Перечень документов, на основании которых создается система ................................... 11 1.5 Плановые сроки начала и окончания работы по созданию системы .............................. 11 1.6 Сведения об источниках и порядке финансирования работ ............................................ 12 1.7 Порядок оформления и предъявления заказчику результатов работ .............................. 12 1.8 Уточнение и дополнение ЧТЗ на систему.......................................................................... 12 2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ ........................................................... 12 2.1 Назначение и цели СКДФ .................................................................................................... 12 2.2 Цели создания СКДФ ........................................................................................................... 14 3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ .................................................... 15 3.1 Объект автоматизации ......................................................................................................... 15 3.2 Участники процесса ............................................................................................................. 15 4 ТРЕБОВАНИЯ К СИСТЕМЕ.................................................................................................. 16 4.1 Требования к Системе в целом ........................................................................................... 16 4.1.1 Требования к структуре и функционированию второй очереди системы ............. 16 4.1.2 Требования к численности и квалификации пользователей системы ................... 22 4.1.3 Требования к надежности........................................................................................... 23 4.1.4 Требования безопасности ........................................................................................... 23 4.1.5 Требования к эргономике и технической эстетике .................................................. 23 4.1.6 Требования к защите информации от несанкционированного доступа ................ 28 4.1.7 Требования по сохранности информации при авариях ........................................... 29 4.1.8 Требования к патентной чистоте ............................................................................... 29 4.2 Требования к видам обеспечения второй очереди СКДФ................................................ 30 4.2.1 Требования к информационному обеспечению ....................................................... 30 4.2.2 Требования к лингвистическому обеспечению ........................................................ 30 4.2.3 Требования к программному обеспечению .............................................................. 31 4.2.4 Требования к техническому обеспечению ............................................................. 101 4.2.5 Требования к метрологическому обеспечению ..................................................... 102 4.2.6 Требования к организационному обеспечению ..................................................... 102 9 4.2.7 Требования к методическому обеспечению ........................................................... 104 5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ ........................... 108 6 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ И ЕЕ СОСТАВНЫХ ЧАСТЕЙ113 6.1 Виды, состав, объем и методы испытаний....................................................................... 113 6.2 Требования к проведению предварительных испытаний............................................... 113 6.3 Требования к проведению опытной эксплуатации ......................................................... 114 6.4 Требования к проведению приемочных испытаний ....................................................... 114 6.5 Требования к проведению комплексных приемочных испытаний ............................... 114 6.6 Требования к передаче дистрибутивов ............................................................................ 115 6.7 Общие требования к приемке работ по этапам ............................................................... 116 ПРИЛОЖЕНИЕ 1 ......................................................................................................................... 117 ПРИЛОЖЕНИЕ 2 ......................................................................................................................... 124 10 1. ОБЩИЕ СВЕДЕНИЯ 1.1 Полное наименование системы и ее условное обозначение: Общедоступная информационная система контроля за формированием и использованием средств дорожных фондов. Условное обозначение – СКДФ, Система. 1.2 Шифр темы или номер договора Присваивается Заказчиком в ходе организации закупочных процедур. 1.3 Наименование заказчика и разработчика Системы Заказчик: Федеральное автономное учреждение «Российский дорожный научноисследовательский институт» (ФАУ «РОСДОРНИИ») Адрес Заказчика: 125493, город Москва, улица Смольная, д. 2 Разработчик (Исполнитель): определяется по результатам закупочных процедур 1.4 Перечень документов, на основании которых создается система п. 8.б.4 Указа Президента Российской Федерации В.В. Путина от 07.05.2018 № 204 «О национальных целях и стратегических задачах развития Российской Федерации на период до 2024 года»; паспорт национального проекта «Безопасные и качественные автомобильные дороги», утвержденный президиумом Совета при Президенте Российской Федерации по стратегическому развитию и национальным проектам (протокол от 24 декабря 2018 г. № 16); паспорт федерального проекта «Общесистемные меры развития дорожного хозяйства», утвержденный протоколом заседания проектного комитета по национальному проекту «Безопасные и качественные автомобильные дороги» от 20 декабря 2018 г. № 4. 1.5 Плановые сроки начала и окончания работы по созданию системы Начало работы – с даты заключения Договора. 11 Окончание работы – 01.12.2020. 1.6 Сведения об источниках и порядке финансирования работ Источником финансирования является бюджет Российской Федерации. Порядок финансирования определяется условиями договора на создание второй очереди СКДФ. 1.7 Порядок оформления и предъявления заказчику результатов работ Оформление и предъявление результатов работ осуществляется в соответствии с требованиями настоящего технического задания и условиями Договора на выполнение работ. 1.8 Уточнение и дополнение ЧТЗ на систему Данное ЧТЗ может уточняться и дополняться выпуском дополнений к нему. Согласование и утверждение дополнений к ЧТЗ проводится в порядке, установленном нормативными правовыми документами и условиями Договора на выполнение работ. 2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ 2.1 Назначение и цели СКДФ СКДФ предназначена для решения задач в интересах различных категорий пользователей и потребителей информации в сфере дорожного хозяйства: владельцев дорог – обеспечивать ведение и поддержку в актуальном состоянии сведений об автомобильных дорогах общего пользования и их участках в цифровой форме, планирование дорожных работ, формирование программ расходования дорожных фондов, мониторинг фактического выполнения работ, обеспечивать обработку и учет сообщений, содержащих информацию пользователей дорожной сети, в том числе для использования при планировании работ; органов государственной власти 12 – обеспечивать информационно- аналитическую поддержку комплексного и детального анализа информации об автомобильных дорогах и истории проведенных работ с учетом гарантийных обязательств, анализа статей формирования и расходования средств дорожных фондов, оперативных и статистических показателей о деятельности отрасли, автоматизацию формирования плановой и управленческой отчетности в электронном виде, предоставлять инструменты поддержки принятия решений на различных уровнях государственного управления дорожной отраслью; коммерческих организаций – обеспечивать доступ к актуальной и достоверной информации об автомобильных дорогах, об участках проведения дорожных работ и планируемых дорожных работ, сведениям об аварийно-опасных участках и состоянии безопасности дорожного движения, а также предоставлять доступ к публичным данным, обрабатываемы СКДФ посредством открытых сервисов информационного обмена и сведениям, публикуемым в формате открытых данных; пользователей дорожной инфраструктуры – предоставлять актуальную информацию об автомобильной дороге в привязке к месту нахождения пользователя (город, улица, район, субъект РФ), возможность отправки сообщения о качестве автомобильных дорог либо предложений в части развития дорожного хозяйства, получать обратную связь от владельцев автомобильных дорог, просматривать информацию об участках проведения и планирования дорожных работ, фактическом их выполнении, сведений о формировании и расходовании средств дорожных фондов с различной детализацией; общественных организаций – предоставление актуальной и достоверной информации об автомобильных дорогах и участках дорог с учетом истории проведенных на них дорожных работ; о планируемых, выполняемых и выполненных дорожных работ и их результатах, о программах расходования дорожных фондов, о формировании дорожных фондов всех уровней, о 13 сообщениях граждан о качестве дорог в привязке к дорогам; участников проектной деятельности - обеспечивать формирование портфеля проектов, ведение паспортов проектов, постановку задач и формирование отчета о выполнении задач проекта, формирование оперативной отчетности о ходе реализации проекта, мониторинг эффективности проектных офисов и контроль исполнительской дисциплины участников проектных офисов и проектов. 2.2 Цели создания СКДФ СКДФ создается в целях формирования и поддержания единой цифровой базы данных в сфере дорожного хозяйства, обеспечения информационно-аналитической поддержки контроля органов государственной власти за формированием и использованием средств дорожных фондов, обеспечения мониторинга различными категориями пользователей процессов формирования и использования средств дорожных фондов всех уровней, а также выполняемых за их счет дорожных работ. 14 3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.1 Объект автоматизации Объектом автоматизации являются процессы, связанные с: обеспечением мониторинга различными категориями пользователей процессов формирования и использования средств дорожных фондов всех уровней; организацией учета сведений об автомобильных дорогах в цифровой форме, их атрибутивных параметров, участков и элементов, а также связанных с дорожными объектами инфраструктурных объектов; подготовкой и реализацией программ и проектов в области дорожного хозяйства, мониторингом хода их реализации и результатов реализации (в том числе за счет анализа обратной связи, поступающей от пользователей дорожной сети), ведения истории проведения работ и инфраструктурных изменений; реализацией получения, обработки и анализа сообщений, поступающих от пользователей дорожной сети; обеспечением проектной деятельности в сфере дорожного хозяйства в соответствии с действующими нормативно-правовыми и организационными документами. 3.2 Участники процесса Участниками процессов, приведенных в п.3.1, являются Министерство транспорта Российской Федерации (Департамент государственной политики в области дорожного хозяйства), Федеральное дорожное агентство, Государственная компания «Российские автомобильные дороги», ФАУ «РОСДОРНИИ», администрации субъектов Российской Федерации и муниципальных образований, заказчики и исполнители (подрядчики), осуществляющие выполнение работ за счет средств дорожных фондов всех уровней. 15 4 ТРЕБОВАНИЯ К СИСТЕМЕ 4.1 Требования к Системе в целом 4.1.1 Требования к структуре и функционированию второй очереди системы В составе СКДФ в целом должны быть созданы следующие прикладные компоненты СКДФ: компонент «Единый цифровой портал дорожной отрасли» (Портал СКДФ), переназначен для предоставления в общедоступной форме сведений и информации обрабатываемых системой в различных форматах и разрезах всем категориям пользователей и потребителей; компонент «Система автоматизации сбора и обработки дорожной статистики в цифровой форме», предназначен для обеспечения сбора, обработки и анализа статистических данных в сфере дорожного хозяйства, формирования отчетов по формам федерального статистического наблюдения о деятельности дорожного хозяйства Российской Федерации, включая данные, относящиеся к формированию и расходованию средств дорожных фондов, оценке технического и эксплуатационного состояния объектов дорожного хозяйства федерального, регионального и местного значения; компонент «Модуль аналитической обработки данных», предназначен для автоматического формирования аналитических отчетов с целью комплексной обработки, сопоставления и представления показателей, рассчитываемых на основе данных, обрабатываемых системой; компонент «Система управления проектной деятельностью», предназначен для обеспечения сквозных процессов и мониторинга проектной деятельности, осуществляемой в сфере дорожного хозяйства в соответствии с применяемым проектным подходом при реализации национальных, федеральных, ведомственных и региональных проектов и государственных программ; компонент «Система обеспечения ведения цифровой базы дорожных 16 объектов, программ и результатов дорожных работ», предназначен для: o обеспечения сквозных процессов ведения единого цифрового реестра объектов дорожного хозяйства, смежных инфраструктурных объектов транспорта, включая атрибутивные параметры, геоинформационные данные и другую сводную информацию; o ведения, учета и мониторинга планов реализации мероприятий на объектах дорожного хозяйства, проведения дорожных работ в рамках программ и проектов на федеральном, региональном и местном уровнях с непосредственным отнесением мероприятий и проводимых работ к объектам дорожного хозяйства (участкам автомобильных дорог); o учета и обработки сведений о фактическом выполнении мероприятий и работ, реализуемых на объектах дорожного хозяйства; o обеспечения процессов сбора, обработки и анализа сообщений граждан о состоянии объектов дорожного хозяйства, как поступающих из внешних источников, так и посредством доступных интерфейсов СКДФ, включая функции доведения сообщений до владельцев объектов дорожного хозяйства и обеспечение обратной связи с лицом, направившим соответствующее сообщение; o формирования и учета документов, подлежащих предоставлению из Единого государственного реестра автомобильных дорог по установленной форме, включая обеспечение юридической значимости документа, как в форме выписки на бумажном носителе, так и в виде электронного документа, подписанного электронной цифровой подписью ответственного за предоставление сведений должностного лица; o обеспечения подтверждения и верификации данных и документов ответственными пользователями автоматизируемых процессов; 17 СКДФ на различных этапах o обеспечения возможности централизованного мониторинга и контроля реализации функций и процессов, реализуемых в рамках СКДФ, включая мониторинг активности и статистики работы пользователей, управления ролевой моделью, контроля качества и регламентов реализации рабочих процессов в системе, ведения мастер-данных, контроля поступления информации из внешних источников, взаимодействия элементов системы между собой и т.д.; o обработки и представления пользователям сведений на основании планов-графиков закупок в сфере дорожного хозяйства, закупок и контрактов, заключаемых по их результатам; o формирования, учета и оформления проектов нормативных документов регионального и местного уровня, определяющих перечни и информацию об автомобильных дорогах соответствующего значения; o автоматизированного определения мест возможного возникновения аварийно-опасных участков (мест концентрации ДТП) на участках дорожной сети; o учета объективных данных (включая фото- и/или видеоматериалы) о ходе и результатах выполнения работ на объекте, получаемых в результате контрольных мероприятий заказчика; o применения алгоритмов и функций, связанных с обеспечением автоматического форматно-логического контроля данных и сведений, обрабатываемых системой, с обеспечением индикации и возможности устранения выявленных ошибок и несоответствий; компонент «Портал подрядной организации», переназначен для планирования и исполнения работ по обязательствам в сфере дорожного хозяйства непосредственно на уровне исполнителей (подрядчиков), выполняющих работы за счет средств дорожных фондов; необходимость и целесообразность создания данного 18 компонента в составе СКДФ обусловлена повышением эффективности реализации процесса «Подготовка и реализация программ и проектов в области дорожного хозяйства, мониторингом хода их реализации и результатов реализации (в том числе за счет анализа обратной связи, поступающей от пользователей дорожной сети), ведения истории проведения работ и инфраструктурных изменений» в части обеспечения возможности получения первичных объективных данных о плане, ходе выполнения и результатах работ непосредственно от исполнителя работ, что позволит снизить нагрузку на заказчика, повысить оперативность получения и качество первичных данных о результатах работ; мобильное рабочее место (приложение) специалиста (РМ «Специалист») из состава комплекса «Мобильные интерфейсы СКДФ», предназначено для обеспечения доступа специалистов, являющихся участниками автоматизируемых процессов, к функциям СКДФ посредством интерфейсов мобильных приложений, устанавливаемых непосредственно на персональные устройства пользователей с учетом их задач и потребностей; мобильное рабочее место (приложение) подрядной организации (РМ «Подрядчик») из состава комплекса «Мобильные интерфейсы СКДФ», предназначено для обеспечения доступа специалистов подрядных организаций, выполняющих работы в за счет средств дорожных фондов, к запланированным работам, а также для подтверждения факта выполнения работ посредством интерфейсов мобильных приложений, устанавливаемых непосредственно на персональные устройства пользователей; мобильное рабочее место (приложение) руководителя (РМ «Руководитель») из состава комплекса «Мобильные интерфейсы СКДФ», предназначено для обеспечения доступа руководителям дорожной отрасли органов власти субъектов РФ, принимающих участие в реализации проектов в сфере дорожного хозяйства, к функциям СКДФ посредством интерфейсов мобильных приложений, устанавливаемых непосредственно на персональные устройства пользователей с учетом их задач и потребностей; 19 мобильное рабочее место (приложение) «Пользователь дорог» из состава комплекса обеспечения «Мобильные доступа интерфейсы широкого круга СКДФ», предназначено пользователей (граждан) для к общедоступным функциям и информации в составе СКДФ с персональных мобильных устройств в условиях отсутствия доступа к стационарному рабочему месту. В целях обеспечения функционирования СКДФ в целом в составе системы предусмотрены платформенные подсистемы в следующем составе: Подсистема информационного взаимодействия с внешними источниками данных (П-ВИД СКДФ) - предназначена для обеспечения информационного взаимодействия СКДФ с внешними информационными системами на основе регулярных процедур обмена данными; Подсистема открытых технологических сервисов предоставления и получения информации (П-ОТС СКДФ) - предназначена для обеспечения механизмов предоставления общедоступных данных, справочников и классификаторов, обрабатываемых системой, широкому кругу внешних абонентов на основе открытых стандартов и механизмов в машиночитаемых форматах, а также получения данных в целях информационного обеспечения СКДФ от абонентов в случае, если сервисом предусматривается двусторонний обмен; Геоинформационная подсистема (П-ГИС СКДФ) - предназначена для обеспечения возможности отображения геоинформационных данных, обрабатываемых СКДФ на электронных картах в интерфейсах прикладного программного обеспечения СКДФ, предоставления геоинформационных сервисов для обеспечения функционирования прикладных компонентов, входящих в состав системы; Подсистема централизованной обработки и хранения данных (П-ОХД СКДФ) - предназначена для обеспечения обработки, хранения, изменения и предоставления доступа компонентам системы ко всему массиву данных, 20 обрабатываемых СКДФ, в соответствии с требованиями к информационному обеспечению системы; Подсистема управления единой нормативно-справочной информацией (ПУНСИ СКДФ) - предназначена для обеспечения качественной (актуальной, полной, непротиворечивой, достоверной и унифицированной) справочной информацией, автоматизации функций формирования и актуализации справочников, классификаторов необходимых для интеграции компонентов СКДФ в части применения НСИ; Подсистема обеспечения функционирования, поддержки пользователей и эксплуатации программно-технических средств (П-ОФП). Требования к СКДФ реализуются как в рамках выполнения работ по настоящему Техническому заданию, так и в рамках отдельных работ в части создания отдельных компонентов и составных частей СКДФ на основании следующих документов: Частное техническое задание на создание первой очереди СКДФ, включая формирование необходимого информационного обеспечения, Частное техническое задание на создание П-ОИБ СКДФ, Частное техническое задание на создание необходимой для функционирования СКДФ аппаратно-программной инфраструктуры. В рамках настоящего технического задания в составе второй очереди СКДФ Исполнителем должны быть созданы следующие компоненты СКДФ: Компонент «Портал подрядной организации»; Мобильное рабочее место (приложение) подрядной организации (РМ «Подрядчик») из состава комплекса «Мобильные интерфейсы СКДФ»; Мобильное рабочее место (приложение) руководителя (РМ «Руководитель») из состава комплекса «Мобильные интерфейсы СКДФ»; Мобильное рабочее место (приложение) «Пользователь дорог» из состава комплекса «Мобильные интерфейсы СКДФ»; Подсистема обеспечения функционирования, поддержки пользователей и 21 эксплуатации программно-технических средств (П-ОФП) второй очереди в объеме требований, предъявляемых настоящим Техническим заданием. При создании компонентов СКДФ и П-ОФП СКДФ по настоящему Техническому заданию Исполнитель должен обеспечить соответствие их общим архитектурным решениям системы, использование и корректное функционирование прикладных компонентов с платформенными подсистемами СКДФ. Создание платформенных подсистем СКДФ (за исключением П-ОФП второй очереди) осуществляется в рамках работ по созданию первой очереди СКДФ, включая формирование необходимого информационного обеспечения, технические требования и решения по платформенным системам содержатся в техническом задании, опубликованном в открытом доступе в Единой информационной системе в сфере закупок (ЕИС, zakupki.gov.ru) под реестровым номером извещения 31908408062. 4.1.2 Требования к численности и квалификации пользователей системы В части общедоступных интерфейсов СКДФ ограничения по численности пользователей должны отсутствовать, а специальные требования к квалификации пользователей, порядку их подготовки и контроля знаний и навыков не предъявляются. Прогнозная общая численность пользователей служебных разделов СКДФ составляет до 60 000 зарегистрированных в системе пользователей. Для обеспечения необходимого уровня квалификации пользователей и проведения обучающих мероприятий Исполнителем в рамках работ по настоящему Техническому заданию должны быть разработаны методические и информационные материалы для всех категорий пользователей и предусмотренных функциональных ролей в части предусмотренных к созданию по настоящему ТЗ составных частей СКДФ. Контроль знаний и навыков пользователей служебных разделов СКДФ должен быть проведен в ходе опытной эксплуатации системы (составных частей Системы) в соответствии с программой ее проведения. 22 4.1.3 Требования к надежности Должен быть обеспечен отказоустойчивый режим функционирования при круглосуточном режиме работы. Среднее время восстановления работоспособности компонентов системы не должно превышать 4 часов. В указанное время входит развертывание и настройка специального программного обеспечения на выделенной инфраструктуре, восстановление данных с использованием последней резервной копии, антивирусная проверка. В указанное время не входит анализ защищенности и выявление причин реализовавшегося деструктивного информационного воздействия. В системе должно быть предусмотрено: контроль целостности данных на уровне СУБД; сохранение целостности данных при нештатном завершении программы (отказ рабочей станции и т.п.); сохранение работоспособности программного обеспечения при вводе некорректного набора данных оператором. 4.1.4 Требования безопасности Безопасность функционирования СКДФ в целом обеспечивается выполнением требований к П-ОИБ СКДФ и услугам по предоставлению инфраструктуры для развертывания СКДФ, которые должны быть выполнены в отдельных работах за рамками работ по настоящему техническому заданию. 4.1.5 Требования к эргономике и технической эстетике 4.1.5.1 Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы, должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части 23 использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть преимущественно на русском языке. Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. Экранные формы должны разрабатываться с учетом требований унификации: все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; 24 внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов. В интерфейсах системы должны присутствовать средства контекстно-зависимой помощи. 4.1.5.2 Пользовательский интерфейс мобильных приложений должен быть максимально простым и понятным в использовании и удовлетворять следующим требованиям: домашняя страница программы должна предоставлять прямой доступ к функциям приложения; процесс навигации должен быть спроектирован таким образом, чтобы пользователь мог определить, где он находится, находился и куда он может переместиться в дальнейшем, не должен оказываться в ситуации, в которой не очевидно, что сейчас происходит и что делать; количество навигационных шагов, необходимых для доступа к определенной части информации, должно быть минимальным; навигационные ссылки должны обозначаться знакомыми пользователю терминами, основанными на его общих знаниях, предыдущем опыте работы в области приложения или опыте пользования другими системами; соответствовать рекомендациям (гайдлайнам) по дизайну и удобству использования платформы, для работы на которой оно создано: для операционной системы iOS должно соответствовать гайдлайнам Apple, для операционной системы Android должно соответствовать гайдлайнам Google; уведомления программы должны соответствовать гайдлайнам платформы и содержать действительно полезную и важную для пользователя информацию, при этом не должно отправляться уведомлений об одном и том же несколько раз подряд, даже если пользователь не ответил и никак на них не отреагировал; должны использоваться стандартные 25 навигационные компоненты платформы: навигационные панели, элементы управления страницами, и не должны меняться системные навигационные функции, если платформа поддерживает кнопку «Назад», нажатие на неё всегда должно вести на предыдущий экран; должны использоваться стандартные жесты платформы: нажатие (Tap), произвольный перенос (Drag), горизонтальный перенос за пределы экрана (Flick), горизонтальный перенос в пределах экрана (Swipe), двойное нажатие (Double tap), перемещение двух пальцев в разные стороны по диагонали (Pinch), нажатие с удержанием (Tap and Hold), встряхивание устройства (Shake), при этом не рекомендуется использование стандартных жестов для выполнения нестандартных действий; не должен скрываться статус-бар операционной системы; отображаемая информация должна быть разборчива (без искажений и потери символов на всех поддерживаемых размерах дисплея и устройствах), её должно быть легко прочесть, распознать или прослушать; должна быть понятна (значение информации понятно, недвусмысленно и интерпретируемо); системные сообщения и результаты действий пользователя должны быть понятными и однозначно трактуемыми; содержать раздел «О приложении», где должно быть указано название мобильного приложения, его текущая версия, авторы-разработчики и их контактные данные; интерфейс должен быть выполнен на русском языке, при этом сам интерфейс (кнопки, формы и т.д.) должен быть адаптирован под длину русскоязычных слов в обеих ориентациях устройства, если изменение ориентации предусмотрено функциональностью приложения (альбомной и портретной); использовать весь экран устройства в обеих ориентациях и предоставлять пользователям идентичную функциональность (в случае, если функциональность приложения предусматривает использование в обеих 26 ориентациях); обрабатывать быстрые переходы между отображением портретной и альбомной ориентаций без проблем визуализации (в случае, если функциональность приложения предусматривает использование в обеих ориентациях); расположение и размер элементов должны быть корректными на всех поддерживаемых устройствах, размерах дисплея и в обеих ориентациях мобильного устройства (в случае, если функциональность приложения предусматривает использование в обеих ориентациях); все элементы должны быть такого размера, чтобы пользователь мог однозначно попасть по ним, не прибегая к использованию интерактивного увеличительного стекла и аналогичных средств; при использовании экрана-заставки или всплывающих окон должна предлагаться очевидная навигационная опция по его пропуску; уведомлять пользователя о долгом времени запуска - показывать индикатор загрузки или сообщения, информирующее пользователя о времени, оставшемся до момента открытия приложения или о прогрессе открытия приложения; отображать графику, текст и другие элементы пользовательского интерфейса без заметных искажений, размытости или пикселизации; обеспечивать достаточное для чёткого отображения качество графики для всех поддерживаемых размеров экрана и устройств; скорость работы мобильного приложения должна быть приемлемой для выполнения задач и достижения целей, для которых создано приложение (не должна негативно сказываться на пользовательском опыте); если мобильное приложение возобновляет свою работу после выхода устройства из заблокированного режима или повторно открывается из меню недавних приложений после использования другого приложения или системной функции, оно должно восстанавливать состояние, максимально 27 близкое к тому, на котором приложение было переведено в фоновый режим (должна продолжаться существующая, а не создаваться новая сессия, если это возможно). При первом запуске приложения пользователям должна быть предоставлена возможность посмотреть короткую инструкцию по использованию приложения, к которой можно будет легко вернуться в дальнейшем. Мобильные приложения должны иметь простой, эффективный и рациональный процесс успешной установки и полного удаления. Мобильные приложения не должны терять данные пользователей после обновления до новой версии. Возможности использования мобильного приложения для достижения определенных целей людьми с ограниченными возможностями не предъявляются. 4.1.6 Требования к защите информации от несанкционированного доступа Требования к защите информации от несанкционированного доступа реализуются средствами подсистемы обеспечения информационной безопасности (ПОИБ) СКДФ. Создание указанной подсистемы осуществляется Заказчиком за рамками настоящего технического задания в рамках отдельных договоров на поставку программного обеспечения информационной безопасности, установку, настройку и пуско-наладку соответствующего ПО, подготовке и проведению аттестационных испытаний, а также сопутствующих работ. В рамках выполнения работ по настоящему Техническому заданию Исполнитель должен обеспечить настройку ПО второй очереди СКДФ на инфраструктуре Заказчика для обеспечения совместного нормального функционирования с средствами П-ОИБ СКДФ, обеспечить участие своих специалистов и представителей при подготовке и проведении совместных приемочных испытаний компонентов и подсистем второй очереди СКДФ и подсистемы П-ОИБ СКДФ в целях обеспечения ввода компонентов второй очереди СКДФ в эксплуатацию. 28 4.1.7 Требования по сохранности информации при авариях Исполнителем в период выполнения работ по Техническому заданию должны быть обеспечены восстановление работоспособности второй очереди СКДФ и сохранность информации после аварий, отказов технических средств и неправильных действий пользователей. 4.1.8 Требования к патентной чистоте Все имущественные права на результаты работ и специально разработанные для Заказчика программные средства должны принадлежать Российской Федерации в лице Заказчика. Требования к программному обеспечению второй очереди СКДФ реализуются в виде самостоятельной разработки программного обеспечения Исполнителем, применения свободно распространяемых платформ и продуктов с открытым исходным кодом. В случае выявления Исполнителем в ходе выполнения работ необходимости изменения отдельных технических решений Исполнитель должен до начала реализации представить обоснование изменения, предусмотренного Техническим заданием решения, и согласовать его с Заказчиком. При этом в составе обоснования Исполнителя должны содержаться сведения и информация, подтверждающие отсутствие влияния предлагаемых решений на функциональные и технические требования к СКДФ второй очереди и СКДФ в целом, обеспечение возможности совместного нормального функционирования элементов системы между собой, а также соответствие предлагаемого решения действующим нормативноправовым документам, в том числе в части импортозамещения программного обеспечения. Использование коммерческого ПО, происходящего из иностранных государств, в соответствии с Постановлением Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» не допускается. 29 4.2 Требования к видам обеспечения второй очереди СКДФ 4.2.1 Требования к информационному обеспечению Исполнителем должна быть разработана и описана структура (модель) базы данных компонентов и составных частей Системы, создаваемых в рамках второй очереди СКДФ, обеспечивающая возможности обработки и хранения данных в системе с целью решения поставленных задач и выполнения функций программного обеспечения. При этом структура данных должна обеспечивать развертывание и функционирование базы данных с использованием свободно распространяемой системы управления базами данных (СУБД) П-ОХД СКДФ, масштабирование и модернизацию с целью увеличения количества и расширения типов обрабатываемых данных. 4.2.2 Требования к лингвистическому обеспечению Специальные требования к лингвистическому обеспечению не предъявляются, интерфейсы и служебные сообщения пользователям должны быть преимущественно реализованы на русском языке. В случаях, когда для каких-либо данных или объектов в системе методическими документами предусмотрено дублирующее или оригинальное значение на иностранном языке, должно быть обеспечено корректное отображение таких наименований. Лингвистическое обеспечение второй очереди СКДФ должно быть достаточным для общения различных категорий пользователей в удобной для них форме со средствами автоматизации СКДФ и для осуществления процедур преобразования и машинного представления обрабатываемой в СКДФ информации. В лингвистическом обеспечении подсистемы должны быть: предусмотрены языковые средства для описания любой используемой в СКДФ информации; унифицированы используемые языковые средства; стандартизированы описания однотипных элементов информации и записи синтаксических конструкций; 30 обеспечены удобство, однозначность и устойчивость общения пользователей со средствами автоматизации СКДФ; предусмотрены средства исправления ошибок, возникающих при общении пользователей с программными средствами СКДФ. Лингвистическое обеспечение системы должно быть отражено в документации (инструкциях, описаниях) организационного обеспечения системы в виде правил общения пользователей с программными средствами второй очереди СКДФ. 4.2.3 Требования к программному обеспечению 4.2.3.1 Общие требования к программному обеспечению второй очереди СКДФ Программное обеспечение СКДФ второй очереди должно состоять из набора прикладных компонентов и функционировать во взаимодействии с платформенными подсистемами СКДФ. Общая структура программного обеспечения СКДФ приведена на Рисунок 1. Разработка прикладных компонентов СКДФ по настоящему Техническому заданию должна вестись с применением средств и технологий, требования к которым содержатся в настоящем разделе Технического задания. В случае, если Исполнителем в ходе выполнения работ будет выявлена целесообразность и/или необходимость применения отличных от указанных в требованиях средств (технологий) и подходов, Исполнителем должны быть подготовлены и направлены в адрес Заказчика соответствующие предложения, содержащие детальное описание предлагаемых изменений, обоснование их применения, включая информацию, подтверждающую отсутствие влияния таких решений на общие требования к системе, требования к совместному взаимодействию ее элементов и показатели функционирования и надежности СКДФ, а также требования к внесению соответствующих изменений в документацию Технического проекта СКДФ. Реализация прикладных компонентов СКДФ в соответствии с предложенными Исполнителем изменениями может быть выполнена только после рассмотрения и письменного согласования Заказчиком предложений Исполнителя. В случае согласования предложений Исполнителем также 31 должны быть внесены изменения в документацию Технического проекта СКДФ в соответствии с предложенными и согласованными требованиями по результатам выполнения работ. Прикладные компоненты Интернет Мобильные интерфейсы Цифровой портал Прикладные компоненты первой очереди СКДФ (в соотв. с требованиями ТЗ) Платформенные подсистемы П-ВИД П-ГИС П-ОТС П-ОХД П-ОИБ П-УНСИ П-ОФП Внешние информационные системы Рисунок 1. Структура программного обеспечения СКДФ Каждый прикладной компонент из состава второй очереди СКДФ должен реализовывать свой набор функций в соответствии с предъявляемыми требованиями, при этом должна быть обеспечена возможность горизонтального масштабирования независимо от других компонентов системы. Техническое решение по обеспечению возможности масштабирования программного обеспечения в составе второй очереди СКДФ должно быть реализовано 32 с учетом технического решения платформы контейнеризации из состава П-ОФП СКДФ. Технологическая структура прикладного программного обеспечения должна соответствовать структуре, представленной на Рисунок 2. Вебклиент Сервис авторизации Каталог безопасности Мобильный клиент Распределитель запросов Сервис обнаружения Программные интерфейсы (сервисы) Интерфейс получения справочников/ классификаторов П-УНСИ Диспетчер очереди сообщений Сервер пространственных данных П-ГИС Обработчик событий изменения данных СУБД П-ОХД Рисунок 2. Технологическая структура прикладного ПО Прикладные компоненты второй очереди СКДФ должны быть реализованы в виде веб-приложения (JavaScript клиенты) (за исключением мобильных приложений). Технологическое решение реализации компонентов предусматривает выделение общих для всех компонентов модулей: модуль «распределитель запросов», модуль «сервис обнаружения», модуль «сервис авторизации». Общие модули организационно должны быть включены в состав цифрового портала. 33 Функционирование клиентских рабочих мест должно быть реализовано за счет отправки запросов по протоколу HTTP (https://tools.ietf.org/html/rfc7230) к модулю «распределитель запросов». Модуль «распределитель запросов» должен обеспечивает решение следующих задач: централизация авторизации и аутентификации; являться источником конфигурации для прикладных компонентов; централизация взаимодействия с API прикладных компонентов и сопоставление сервисов с URL; контроль прохождения запроса; управление кешированием ответов; управление распространением статического контента; балансировка нагрузки между различными экземплярами прикладных сервисов (в случае наличия доступа к ним). Модуль «распределитель запросов» реализуется с использованием подхода – stateless – без сохранения состояния, и обеспечивать при необходимости возможность горизонтального масштабирования всей системы. Модуль «сервис обнаружения» обеспечивает хранение и поддержание в актуальном состоянии списка доступных в системе сервисов, мониторинг нагрузки на прикладные сервисы и определение состояния наборов данных. Реализация списков сервисов обеспечивается с использованием шаблонов проектирования «реестр» и «состояние» (State and Registry), когда под каждую группу идентичных сервисов, создается свой объект реестра, который сохраняет состояние каждого из сервисов в этой группе. Обновление состояний каждого из сервисов происходит при помощи опроса соответствующего сервиса, а также при анализе очереди сообщений, отвечающей за состояние сервисов и данных. Модуль «сервис обнаружения» включает в себя: клиентскую библиотеку, содержащую набор абстракций и реализацию, необходимую для обнаружения сервиса и публикацию изменений его 34 состояния с течением времени; механизмы мониторинга, обеспечивающие опрос сервисов и обработку их сообщений, и возможность изменять сохраненные состояния; механизмы предоставления списка сервисов, удовлетворяющих требованиям запрашивающей стороны. Клиентская библиотека модуля «сервис обнаружения» включает в себя средства мониторинга конечного сервиса, а также способы передачи состояния сервиса и имеет возможность встраивания в конвейер обработки запроса ASP.NET Core (https://docs.microsoft.com/ru-ru/aspnet/core/?view=aspnetcore-2.2), предоставляет отчет о состоянии сервиса в формате JSON (https://tools.ietf.org/html/rfc7159) по протоколу HTTP (https://tools.ietf.org/html/rfc7230). Клиентская библиотека модуля «сервис обнаружения» реализует функционал отправки сообщений в очередь (диспетчер очередей сообщений входит в состав ПОХД) об отказе в работе и o последующем восстановлении, за счет чего реализуется функция автоматического обнаружения сервисов. Алгоритм работы клиентской библиотеки модуля «сервис обнаружения» предусматривает следующий порядок работы: после запуска сервиса в очередь, публикуется сообщение о начале работы, содержащее всю необходимую информацию о сервисе; за счет автоматической отправки сообщений о начале работы, реализуется механизм автоматического обнаружения сервисов; в последующем, информация о сервисе запрашивается через протокол HTTP. Обработка HTTP запросов на мониторинг состояния сервиса реализуется в виде промежуточного слоя с настройкой через методы расширения и установкой всех необходимых параметров. При этом хранение информации о сервисе должно быть вынесено в конфигурацию. В целях поддержки функций обработки транзакций и поддержания актуальности набора данных, должны быть реализованы возможности обмена номерами обработанных транзакций за счет применения отдельной темы в диспетчере очереди сообщений из состава П-ОХД СКДФ, в которую должна отправляться структура, 35 упакованная по протоколу Protocol Buffers (https://developers.google.com/protocolbuffers/docs/proto3?hl=ru): IP адрес – упакованный в int; Порт – uint; Номер последней транзакции – ulong. Размер сообщения об обработанной транзакции должен составлять 16 байт. Очередь обработки транзакций должна обнуляться совместно с основным потоком транзакций в диспетчере сообщений. В сообщении об обработке транзакции должен указываться внешний IP адрес и порт базы данных, в которую сервис произвел запись. Механизмы мониторинга модуля «сервис обнаружения» должны обеспечивать возможность определения состояния сервисов, посредством опроса сервисов по протоколу HTTP и анализа состояний очередей с информацией о сервисе, а также об обработанных сервисом транзакциях. Опрос сервисов должен проводиться с небольшой периодичностью, поскольку внутри сервиса должны использоваться механизмы самодиагностики и обработки ошибок, а в случае критичных ситуаций сервис должен публиковать соответствующее сообщение. За счет осуществления запросов должна обеспечиваться проверка на внешние критичные ситуации: ошибки сети, неработоспособность контейнера или операционной системы, отказ в обслуживании приложения-сервиса и т.д. Периодичность опросов должна настраиваться через конфигурацию сервиса обнаружения. Однонаправленность потока данных о сервисах в системе должна гарантироваться единственностью возможности изменения содержимого реестра сервисов. В целях обеспечения адекватной реакции на изменение адресов сервисов, оперативной обработки ситуации исключения сервиса из системы, экономии ресурсов на опрос выключенных или несуществующих сервисов, механизмы мониторинга модуля «сервис обнаружения» должны обеспечивать ведение подсчета количества 36 опросов, в результате которых обнаружена неработоспособность сервиса. По достижению определенного количества попыток (задается в конфигурации), сервис должен исключаться из списка проверки. Механизмы предоставления списка сервисов модуля «сервис обнаружения» должны обеспечивать выдачу списка сервисов согласно устанавливаемым параметрам. Перечень и формат параметров фильтрации и результатов выдачи должны быть определены на этапе разработки рабочей документации. В конфигурации каждого сервиса должно быть указано, требует ли он авторизацию или является публичным. Публичные программные интерфейсы не требуют авторизации или позволяют использовать внешние системы авторизации. В части доступа к корпоративным (закрытым) программным интерфейсам (сервисам) запросы должны проверяться на наличие метки безопасности в соответствии с протоколом OAuth 2.0 (https://tools.ietf.org/html/rfc6749), и в случае отсутствия метки безопасности должно быть обеспечено перенаправление запроса на внутренний сервис авторизации. Для осуществления идентификации, аутентификации и авторизации должно быть обеспечено взаимодействие сервиса авторизации с каталогом безопасности. Каталог безопасности реализован на базе программного обеспечения с открытым исходным кодом OpenLDAP (http://www.openldap.org/). Каталог безопасности должен обеспечивать следующие функции: централизованное ведение учетных записей пользователей; централизованное ведение ролевой модели системы; управление политиками паролей для доступа к системе; предоставление программного интерфейса доступа к каталогу безопасности по стандартизированному протоколу LDAP (https://tools.ietf.org/html/rfc4511) для прикладных компонентов и платформенных подсистем СКДФ. После успешной авторизации клиенту должна выдаваться метка безопасности для работы в системе. В метке должна содержаться информация об учетной записи 37 пользователя и его функциональных группах (ролях). Метка должна представлять собой JSONWebToken (JWT) - https://tools.ietf.org/html/rfc7519, для получения метки должен использоваться протокол OpenIDConnect 1.0 (https://openid.net/specs/openidconnect-core-1_0.html), который является расширением протокола OAuth 2.0 для обеспечения аутентификации. Наличие доступа к интерфейсам прикладных компонентов должно проверяться распределителем запросов по наличию функциональных ролей в метке безопасности. Каждый интерфейс прикладных компонентов должен быть реализован в виде независимого сервиса (группы сервисов в случае масштабирования). Сервисы должны обрабатывать запросы пришедшие от клиентов. При обработке запросов сервисы должны использовать функции программного обеспечения платформенных подсистем СКДФ в зависимости от типа и характера запроса. Прикладные компоненты СКДФ должны разрабатываться в архитектуре вебприложений. Веб интерфейс должен быть реализован по технологии одностраничного приложения – использоваться единый HTML-документ как оболочка для веб-страниц, а взаимодействие с пользователем организовано через динамически подгружаемый контент. Разработка веб-интерфейса должна быть основана на языке программирования JavaScript. Для разработки веб-интерфейсов прикладных компонентов СКДФ должна использоваться среда React (https://ru.reactjs.org/). Сервисы прикладных компонентов должны представлять собой набор программных интерфейсов, реализованных на программной платформе .NET Core 2 (https://docs.microsoft.com/ru-ru/dotnet/core/). Разработка сервисов должна вестись с использованием языка программирования C# (https://www.ecma- international.org/publications/standards/Ecma-334.htm). Мобильные интерфейсы должны быть разработаны с использованием платформы Xamarin (https://docs.microsoft.com/ru-ru/xamarin/). Встраивания в общие модули системы должны быть реализованы по протоколу HTTP (https://tools.ietf.org/html/rfc7230). 38 Доступ к данным должен быть организован через язык SQL, стандарт ISO/IEC 9075 “Database Language SQL”, версия SQL:2011. Разработка процедур обработки данных должна вестись на процедурном расширении языка SQL. Базовой операционной системой для всех компонентов СКДФ первой очереди является CentOS Linux 7.5. CentOS является свободно распространяемым дистрибутивом Linux, основанным на коммерческом дистрибутиве Red Hat Enterprise Linux компании Red Hat и совместимый с ним. Порядок установки данной ОС описан в документе по ссылке https://docs.centos.org/en-US/centos/install-guide/. Шаблон виртуальной машины на базе данной ОС должен использоваться для создания хостов всех компонентов первой очереди СКДФ. 4.2.3.2 Требования к компоненту «Портал подрядной организации» В рамках создания компонента «Портал подрядной организации» должны быть реализованы следующие функциональные модули: просмотр цифровой базы дорожных объектов (п. 4.2.3.2.1); планирование работ на дорожных объектах (п. 4.2.3.2.2); исполнение работ на дорожных объектах (п. 4.2.3.2.3). Компонент «Портал подрядной организации» должен обеспечивать исполнение процесса выполнения работ по договорному обязательству подрядной организацией. В зависимости от категории работ обязательства (содержание, ремонт, капительный ремонт, реконструкция, строительство) и при наличии значимых различий в процессах исполнения обязательств разных категорий работ функциональные возможности модулей компонента «Портал подрядной организации» могут быть разделены на несколько разделов для удобства работы пользователей компонента. Для пользователя с ролью администратора компонента «Портал подрядной организации» должны быть предусмотрены возможности настройки параметров, используемых в работе компонентов «Подрядная организация» и РМ «Подрядчик», а также управления очередью отложенных задач, возникающих на Портале подрядной организации (п. 4.2.3.2.5). 39 Должно быть обеспечено отображение справочников НСИ на Портале подрядной организации, используемых в процессах подрядных организаций по планирование и исполнению договорных обязательств. Требования к отображению справочников представлены в п. 4.2.3.2.6. 4.2.3.2.1 Требования к модулю «Просмотр цифровой базы дорожных объектов» Модуль «Просмотр цифровой базы дорожных объектов» должен обеспечивать возможность просмотра сведений о дорожных объектах (участках проведения работ), зарегистрированных в СКДФ, на которых подрядная организация подрядчика выполняет работы в рамках договорных обязательств. В рамках создания модуля «Просмотр цифровой базы дорожных объектов» должны быть реализованы следующие функциональные возможности: отображение перечня дорожных объектов, включенных в договорные обязательства подрядчика, зарегистрированные в СКДФ, в следующих режимах: o в виде реестра в составе следующих основных характеристик: 1. наименование; 2. владелец; 3. значение (местное, региональное/межмуниципальное, федеральное); 4. протяженность, км; 5. начало участка; 6. конец участка; 7. категория дороги; 8. вид покрытия; o на карте; поиск дорожных объектов (в обоих режимах – в виде реестра и на карте) по основным характеристикам: o наименование; 40 o владелец; o значение; o регион; o район; o категория дороги; o вид покрытия; просмотр сведений о дорожном объекте (при выборе объекта из любого режима – из реестра, с карты) в составе следующих сведений: o наименование; o владелец; o значение; o регион; o район; o категория дороги; o вид покрытия; o протяженность, км; o начало участка; o конец участка; o другие количественные, протяженные и площадные числовые характеристики дорожного объекта (перечень характеристик должен быть согласован с Заказчиком при проведении работ по данному Техническому заданию); выгрузка реестра дорожных объектов в открытом структурированном формате (OpenDocument Format) табличного редактора; выгрузка сведений о дорожном объекте в открытом структурированном формате (OpenDocument Format). 4.2.3.2.2 Требования к модулю «Планирование работ на дорожных объектах» Модуль «Планирование работ на дорожных объектах» должен обеспечивать возможность составления и управления планом-графиком работ на дорожных 41 объектах, включенных в договорные обязательства организации-подрядчика. Планирование должно быть доступно как на один дорожный объект, так и на группу объектов. В рамках создания модуля «Планирование работ на дорожных объектах» должно быть обеспечено решение следующих задач: объединение участков проведения работ по содержанию в группы объектов; планирование работ по исполнению договорных обязательств. 4.2.3.2.2.1 Объединение участков проведения работ по содержанию в группы объектов Назначение: упрощение процесса планирования одного вида работы по содержанию на множестве участков, а также определение эталонного трека, в соответствии с которым специалист организации-подрядчика должен выполнять работу по содержанию с использованием РМ «Подрядчик». Для решения данной задачи должны быть реализованы следующие функции: просмотр реестра групп объектов (дистанций); поиск дистанций в реестре по основным характеристикам: o участок проведения работ, включенный в дистанцию; o заказчик договорного обязательства; o договорное обязательство, в рамках которого действует дистанция; o вид работы, который можно выполнить на дистанции в соответствии с условиями обязательства на выполнение работ (поиск дистанции, в которой по всем включенным участкам можно выполнять указанный вид работы в соответствии с условиями обязательства); o наименование дистанции; o статус (подтверждена, проект); объединение участков проведения работ в дистанции в рамках одного договорного обязательства; отображение перечня видов работ в карточке дистанции, которые можно выполнить на каждом участке дистанции в соответствии с условиями 42 обязательства на выполнение работ. Данный перечень предназначен для контроля включения в дистанцию участков с одинаковой периодичностью выполнения регламентных работ, а также гарантирует возможность выполнения вида работы на каждом участке дистанции без исключений. Виды работ должны автоматически подтягиваться при добавлении участка в дистанцию из локального сметного расчета договорного обязательства и автоматически корректироваться при удалении участка из дистанции; изменение данных дистанции до ее подтверждения в части следующих сведений: o наименование дистанции; o договорное обязательство – при изменении договорного обязательства перечень участков проведения работ и видов работ должен очищаться; o перечень участков проведения работ; просмотр данных дистанции; утверждение дистанции (дистанция должна быть доступна для планирования работ на ней только после ее утверждения); удаление неподтвержденной дистанции физически из БД (удаление подтвержденной дистанции должно быть невозможно); создание дистанции на основе существующей – при этом из исходной дистанции должны копироваться участки проведения работ, которые есть в указанном контракте создаваемой дистанции; просмотр на карте участков проведения работ договорного обязательства в трех разрезах: o участки, включенные в текущую дистанцию; o участки, включенные в другие дистанции; o участки, не вошедшие ни в одну дистанцию; выгрузка реестра дистанций в открытом структурированном формате (OpenDocument Format) табличного редактора; выгрузка сведений о дистанции в открытом структурированном формате 43 (OpenDocument Format). 4.2.3.2.2.2 Планирование работ Для решения данной задачи должны быть реализованы следующие функциональные возможности: просмотр перечня планов работ по договорным обязательствам организацииподрядчика в следующих режимах: o в виде реестра; o на карте; o на календаре; поиск запланированных работ (во всех режимах – в виде реестра, на карте, на календаре) по основным характеристикам: o категория работы; o договорное обязательство; o объект работ (участок проведения работ, дистанция); o вид работы; o плановая дата; o фактическая дата выполнения работы; планирование точечных работ по содержанию дорожных объектов (в т.ч. ямочного ремонта) в следующем объеме: o создание плановой работы (во всех режимах – из реестра, с карты, на календаре) в составе следующих характеристик: 1. договорное обязательство; 2. объект выполнения работы; 3. вид работы; 4. плановая дата выполнения работы; 5. объем работы; o автоматический расчет объема работ при создании плановой работы в зависимости от настроек в справочнике видов работ (связь вида работы с характеристикой участка проведения работ) и заполнения 44 характеристики участка проведения работ (настройка связей видов работ с характеристиками участка проведения работ должна осуществляться Оператором системы); o изменение данных плановой работы до получения сведений о ее выполнении; o удаление не выполненной плановой работы (функция должна быть доступна не позднее чем за 3 дня до запланированной даты). Удаление физическое из БД; o отмена не выполненной плановой работы – при отмене плановой работы должен проставляться признак отмены (статус) и взятие в работу отмененного плана в РМ «Подрядчик» после отмены становится недоступно; o просмотр данных плановой работы; o выгрузка перечня планов работ в открытом структурированном формате (Open Document Format) табличного редактора; o учет и просмотр сведений о факте выполнения плана (дата, исполнитель, фото подтверждение, геометрия); планирование линейных работ по содержанию дорожных объектов в следующем объеме: o создание плановой работы (во всех режимах – из реестра, с карты, на календаре) с учетом контроля превышения максимального количества циклов, предусмотренных регламентными требования к выполнению работ (настройка связей видов работ с характеристиками участка проведения работ должна осуществляться Оператором системы); o автоматический расчет объема работ при создании плановой работы в зависимости от настроек в справочнике видов работ (связь вида работы с характеристикой участка проведения работ) и заполнения характеристики участка проведения работ (настройка связей видов 45 работ с характеристиками участка проведения работ должна осуществляться Оператором системы); o изменение данных плановой работы до получения сведений о ее выполнении; o удаление не выполненной плановой работы (функция должна быть доступна не позднее чем за 3 дня до запланированной даты). Удаление физическое из БД; o отмена не выполненной плановой работы – при отмене плановой работы должен проставляться признак отмены (статус) и взятие в работу отмененного плана в РМ «Подрядчик» после отмены становится недоступно; o просмотр данных плановой работы; o выгрузка перечня планов работ в открытом структурированном формате (OpenDocument Format) табличного редактора; o учет и просмотр сведений о факте выполнения плана (дата, исполнитель, геометрия); планирование работ по ремонту, строительству, реконструкции, капитальному ремонту дорожных объектов в следующем объеме: o автоматизированное создание плана-графика работ по этапам работ (требования к механизму управления расчетом плана графика представлены в п. 4.2.3.2.5.5 ЧТЗ); o изменение плана-графика работ по этапам до внесения сведений о фактическом выполнении работ; o выгрузка плана-графика работ по этапам в открытом структурированном формате (OpenDocument Format) табличного редактора; o учет и просмотр сведений о факте выполнения плана работ по этапам. 4.2.3.2.3 Требования к модулю «Исполнение работ на дорожных объектах» 46 Модуль «Исполнение работ на дорожных объектах» должен обеспечивать возможность учета сведений о фактическом исполнении работ по договорным обязательствам в сфере дорожного хозяйства, подтверждения объемов выполненных работ мастерами со стороны подрядчика, а также ведения журнала выполненных работ. В рамках создания модуля «Исполнение работ на дорожных объектах» должно быть обеспечено решение следующих задач: подтверждение выполненных работ по договорным обязательствам; ведение журнала выполненных работ по договорным обязательствам; ведение журнала укладки а/б смеси. 4.2.3.2.3.1 Подтверждение выполненных работ по договорным обязательствам Назначение: учет сведений о фактическом исполнении работ по договорным обязательствам в сфере дорожного хозяйства, полученных из РМ «Подрядчик», а также подтверждение объемов выполненных работ мастерами со стороны подрядчика. Для решения данной задачи должны быть реализованы следующие функциональные возможности: учет сведений о фактическом выполнении точечных работ по содержанию дорожных объектов, полученных из РМ «Подрядчик»; учет сведений о фактическом выполнении линейных работ по содержанию дорожных объектов, полученных из: o из внешних систем. В целях выполнения данного требования Исполнителем в рамках работ по настоящему Техническому заданию должны быть разработаны описания состава и формата данных, подлежащих передаче и программный интерфейс получения данных из внешних систем, при этом описание состава и формата данных должно быть предварительно согласовано с Заказчиком; o РМ «Подрядчик». Данный способ подтверждения объемов выполненных линейных работ является альтернативным и может использоваться подрядными организациями при отсутствии у них 47 специализированных средств для подтверждения объемов выполненных линейных работ, записывающих трек прохождения транспортным средством; распределение объема фактически выполненной работы, указанного пользователем в РМ «Подрядчик», по участкам проведения работ в соответствии со значениями соответствующих характеристик участков проведения работ (настройка связей видов работ с характеристиками участка проведения работ для автоматизированного расчета должна осуществляться Оператором системы); ведение Реестра подтверждения выполненных работ, содержащего сведения о фактическом исполнении запланированных работ, а также о решении, принятом пользователем по выполненным работам (не отработано, подтверждено, отклонено, возвращено на доработку); поиск записей в Реестре подтверждения выполненных работ по основным характеристикам: o договорное обязательство; o объект выполнения работ (участок проведения работ, дистанция); o категория работы; o вид работы; o плановая дата выполнения работ; o фактическая дата выполнения работ; o просроченные не исполненные плановые работы; просмотр сведений записи Реестра подтверждения выполненных работ в составе основных характеристик: o плановая дата выполнения работы; o фактическая дата выполнения работы; o исполнитель работы; o объем работы (плановый, фактический); o геометрия (плановая, фактическая); 48 o фото/видео подтверждение выполнения работы; принятие решения по выполненной работе: o подтверждение работ, при котором автоматически должна создаваться запись о подтвержденной выполненной работе в: 1. Журнале выполненных работ (требования к ведению Журнала выполненных работ представлены в п. 4.2.3.2.3.2 ТЗ); 2. Журнале укладки а/б смеси (для работ, по которым выполняется этап укладки а/б смеси. Требования к ведению Журнала укладки а/б смеси представлены в п. 4.2.3.2.3.3 ТЗ); o отклонение работ, при котором автоматически должна создаваться запись об отклоненной выполненной работе в: 1. Журнале выполненных работ (требования к ведению Журнала выполненных работ представлены в п. 4.2.3.2.3.2 ТЗ); 2. Журнале укладки а/б смеси (для работ, по которым выполняется этап укладки а/б смеси. Требования к ведению Журнала укладки а/б смеси представлены в п. 4.2.3.2.3.3 ТЗ); o возврат работы на доработку в РМ «Подрядчик». Данная функция должна использоваться при необходимости внести дополнительные сведения или скорректировать сведения о фактическом исполнении работ (например, заменить фото подтверждение); изменение выполненной работы в части привязки ее к другой плановой работе до принятия решения по выполненной работе; пересчет объема выполненной работы на основании скорректированных сведений о дорожных объектах: o изменение количественных, протяженных и площадных характеристик дорожных объектов; o изменения геометрии дорожных объектов; o изменении привязки характеристик дорожных объектов к видам работ и/или корректировки параметров расчета объемов работ; 49 выгрузка Реестра подтверждения выполненных работ в открытом структурированном формате (OpenDocument Format) табличного редактора. 4.2.3.2.3.2 Ведение журнала выполненных работ по контрактам Для решения данной задачи должны быть реализованы следующие функции: ведение Журнала выполненных работ по контрактам в следующих режимах: o в виде реестра; o на карте; o на календаре. Данные должны создаваться в журнале автоматически при принятии решения по выполненной работе (требования к функциям принятия решения представлены в п. 4.2.3.2.3.1 ТЗ) в составе следующих данных: o договорное обязательство; o дата и время начала работы; o дата и время завершения работы; o участок проведения работ; o пикетаж (начало); o пикетаж (конец); o сторона на участке; o вид работы; o объем работы; o единица измерения объема работы; o погодные условия проведения работ; o исполнитель (ФИО, должность); o пользователь, принявший решение о выполненной работе (ФИО, организация, должность); o фото-/видеоматериалы; o геометрия; поиск записей в Журнале выполненных работ по основным характеристикам: o заказчик выполнения работ по договорному обязательству; 50 o категория работ; o договорное обязательство; o дата выполнения работы; o участок проведения работ; o вид работы; просмотр записи Журнала выполненных работ; изменение данных записи Журнала выполненных работ; удаление записей Журнала выполненных работ; выгрузка Журнала выполненных работ в открытом структурированном формате (OpenDocument Format) табличного редактора. 4.2.3.2.3.3 Ведение журнала укладки а/б смеси Журнал укладки а/б смеси должен вестись по работам, предусматривающим этап укладки а/б смеси. Для решения данной задачи должны быть реализованы следующие функции: ведение Журнала укладки а/б смеси работ по обязательствам в следующих режимах: o в виде реестра; o на карте; o на календаре. Данные должны создаваться в журнале автоматически при принятии решения по выполненной работе (требования к функциям принятия решения представлены в п. 4.2.3.2.3.1 ТЗ) в составе следующих данных: o дата и время начала работы; o дата и время завершения работы; o тип и марка а/б смеси; o температура а/б смеси, С˚; o пикетаж (начало); o пикетаж (конец); o сторона участка; 51 o вид работы; o объем выполненной работы; o единица измерения объема выполненной работы; o расход смеси (нижний слой), т; o расход смеси (верхний слой), т; o брак смеси, т; o количество рабочих катков; o марка и вес катка; o температура воздуха, С˚; o погодные условия; o исполнитель (ФИО, должность); o пользователь, принявший решение о выполненной работе (ФИО, организация, должность); o фото-/видеоматериалы; o геометрия; поиск записей в Журнале укладки а/б смеси по основным характеристикам: o заказчик выполнения работ; o обязательство; o дата выполнения работы; o участок проведения работ; o вид работы; просмотр записи Журнала укладки а/б смеси; изменение данных записи Журнала укладки а/б смеси; удаление записей Журнала укладки а/б смеси; выгрузка Журнала укладки а/б смеси в открытом структурированном формате (OpenDocument Format) табличного редактора. 4.2.3.2.4 Требования к модулю обязательством» 52 «Единая форма управления Модуль «Единая форма управления обязательством» должен обеспечивать возможность учета всех этапов исполнения обязательства в рамках единой формы. В рамках создания модуля «Единая форма управления обязательством» должен быть реализован реестр, содержащий обязательства, заключенные с подрядной организацией, работа по которым осуществляется на «Портяле подрядной организации». Открытая форма обязательства должна представлять собой Единую форму управления обязательством, состоящую из набора разделов. В рамках решения данной задачи должны быть реализованы следующие функции: просмотр реестра обязательств, заключенных с подрядчиком; поиск обязательств в реестре по основным параметрам: o наименование обязательства; o номер обязательства; o заказчик выполнения работ; o период выполнения работ по обязательству; просмотр кратких сведений об обязательстве; планирование работ по обязательству (требования к планированию представлены в п. 4.2.3.2.2 ТЗ) в следующем объеме: o объединение участков проведения работ в группы объектов (дистанции) – данная функция должна быть реализована для обязательств по содержанию дорожных объектов; o планирование работ; учет фактов выхода на объект выполнения работ (для работ по ремонту, строительству, реконструкции, капитальному ремонту) в составе следующих данных: o дата и время выхода на объект; o ФИО исполнителя работ; o видео подтверждение выхода на объект; o комментарий. 53 Данные о факте выхода на объект должны загружаться из РМ «Подрядчик»; подтверждение выполненных работ по обязательству (требования к функциям подтверждения работ представлены в п. 4.2.3.2.3.1 ТЗ); ведение Журнала выполненных работ по обязательству (требования к ведению Журнала выполненных работ представлены в п. 4.2.3.2.3.2 ТЗ); ведение Журнала укладки а/б смеси (требования к ведению Журнала укладки а/б смеси представлены в п. 4.2.3.2.3.3 ТЗ); автоматическое формирование сравнительной ведомости по работам обязательства в следующем объеме: o вид работы; o объем по проектно-сметной документации (по обязательству); o объем с изменением согласно протоколу (фактически выполненный объем); o разница; o единица измерения объема работы; прикрепление документов, подтверждающих выполнение работ: o заключение о качестве выполненных работ (документ должен формироваться организацией, проводящей проверку. Исполнитель работ по контракту должен приложить готовый документ на Портал подрядной организации); o акты выполненных работ по форме КС-2; o справки о стоимости выполненных работ по форме КС-3 (для государственных и муниципальных контрактов, исполнителями по которым являются коммерческие организации); o платежные документы, подтверждающие оплату выполненных работ, а также штрафов, выставленных заказчиком обязательства в соответствии с поданными претензиями к подрядной организации; o акт передачи участка в работу (перечень категорий работ обязательства, для которых должны прикладываться документы 54 данного типа, должен быть согласован с Заказчиком при выполнении работ по настоящему ТЗ); o уведомление о начале работ на участке (перечень категорий работ обязательства, для которых должны прикладываться документы данного типа, должен быть согласован с Заказчиком при выполнении работ по настоящему ТЗ); o акты освидетельствования выполненных и скрытых работ на участке (перечень категорий работ обязательства, для которых должны прикладываться документы данного типа, должен быть согласован с Заказчиком при выполнении работ по настоящему ТЗ); o уведомление о завершении работ на участке (перечень категорий работ обязательства, для которых должны прикладываться документы данного типа, должен быть согласован с Заказчиком при выполнении работ по настоящему ТЗ). 4.2.3.2.5 Требования к функциям администратора компонента «Портал подрядной организации» Пользователь с ролью администратора компонента «Портал подрядной организации» должен иметь возможность управления заданиями на выполнение работ и параметрами, необходимыми для функционирования компонента «Портал подрядной организации» и РМ «Подрядчик». Должно быть обеспечено решение следующих административных задач: управление заданиями для РМ «Подрядчик» (п. 4.2.3.2.5.1 ЧТЗ); управление очередью отложенных задач Портале подрядной организации (п. 4.2.3.2.5.2 ЧТЗ); управление параметрами компонентов «Портал подрядной организации» и РМ «Подрядчик» (п. 4.2.3.2.5.3 ЧТЗ); ведение журнала событий, возникающих при работе на Портале подрядной организации (п. 4.2.3.2.5.4 ЧТЗ); управление расчетом плана-графика по этапам выполнения работ (п. 55 4.2.3.2.5.5 ЧТЗ). 4.2.3.2.5.1 Управление заданиями для РМ «Подрядчик» Назначение: просмотр сформированных заданий на выполнение работ по контрактам, управление периодом видимости заданий в РМ «Подрядчик». Для решения данной задачи должны быть реализованы следующие функции: просмотр реестра заданий на выполнение работ; поиск заданий в реестре по заданным параметрам: o тип задания; o ID задания; o период выполнения работ; o отмененные/неотмененные задания; o выполненные задания; просмотр сведений о сформированном задании; просмотр сведений о факте выполнения задания; массовая отмена задания; изменение периода доступности задания; экспорт реестра заданий в открытом структурированном формате (OpenDocument Format) табличного редактора. 4.2.3.2.5.2 Управление очередью отложенных задач Назначение: учет сведений (задач) в формате JSON, полученных из РМ «Подрядчик», для дальнейшей порционной распаковки в соответствующие разделы компонента «Портал подрядной организации» при отсутствии ошибок обработки входного JSON-сообщения. В случае возникновения ошибок обработки JSON должно формироваться сообщение об ошибке. Администратор приложения должен иметь возможность перезапустить задачу с ошибкой после исправления причин возникновения ошибки. Для решения данной задачи должны быть реализованы следующие функции: ведение реестра «Очередь отложенных задач» в составе следующих 56 характеристик: o ID задачи; o логин пользователя, отправившего данные; o UID полученных данных; o дата получения данных; o дата обработки задачи; o сообщение об ошибке, возникшей при обработке данных; поиск в реестре по основным характеристикам: o UID полученных данных; o логин пользователя; o сообщение об ошибке; o только необработанные задачи; o период получения данных; просмотр данных задачи; остановка текущей обработки задач; перезапуск задачи с ошибкой после исправления причин возникновения ошибки. 4.2.3.2.5.3 Управление параметрами компонентов «Портал подрядной организации» и РМ «Подрядчик» Назначение: изменение значений параметров, используемых в работе компонента «Портал подрядной организации» и РМ «Подрядчик» - например, значения констант, определяющих различные пороговые значения. Для решения данной задачи должны быть реализованы следующие функции: ведение реестра параметров в составе основных характеристик: o ID; o код параметра; o наименование параметра; o описание параметра; o значение параметра; 57 o дата создания записи; o дата начала действия значения параметра; o дата окончания действия значения параметра; o дата изменения значения параметра; поиск в реестре по следующим параметрам: o код; o наименование; o значение; o только актуальные значения параметров; создание параметра в составе основных характеристик: o код; o наименование; o описание; o значение. 4.2.3.2.5.4 Ведение журнала событий Должна быть реализована возможность просмотра деталей логирования событий, происходящих в компоненте «Портал подрядной организации», таких как: изменение характеристик объектов; возникновение ошибок в компоненте; загрузка данных; запуск задач по расписанию и др. Журнал событий должен отображаться в составе следующих основных характеристик: дата и время возникновения события; пользователь, под учетной записью которого возникло событие; категория события; сессия. Должны быть реализованы фильтрация журнала событий по заданным параметрам и возможность просмотра описания возникшего события. 58 4.2.3.2.5.5 Управление расчетом плана-графика по этапам выполнения работ Назначение: обеспечение гибкой настройки процесса расчета плана-графика по этапам выполнения работы (при наличии в обязательстве явного разделения работ на последовательные этапы) в условиях изменяемых требований к выполнению работ. Перечень категорий работ, для которых актуально поэтапное последовательное выполнение работ, должен быть согласован с Заказчиком во время выполнения работ по настоящему ЧТЗ. Перечень этапов работ в зависимости от категории должен вестись в рамках Подсистемы управления единой нормативно-справочной информацией (П-УНСИ СКДФ) Оператором системы. Все виды работ, выполняемые в рамках этапа, должны быть промаркированы Оператором системы. Должны быть реализованы следующие функциональные возможности: определение последовательности выполнения этапов работ; определение доли времени, необходимого на выполнение этапа работы на участке, относительно общего планового периода выполнения работ на участке; указание признака необходимости ведения Журнала укладки а/б для этапа работ. Требования к отображению справочников компонента «Портал 4.2.3.2.6 подрядной организации» Назначение: обеспечение быстрого доступа к справочной информации, используемой на Портале подрядной организации. Должно быть реализовано отображение следующих справочников: данные организаций; ФИАС; регламенты на выполнение работ в составе следующих данных: o вид работы; o максимальное количество циклов, выполняемых за сезон (зима, лето); виды обязательств (государственные 59 и муниципальные контракты, государственные и муниципальные задания и др.); должности; виды работ; единицы измерения (с учетом правил конвертации единиц измерения); типы вложений, которые можно добавить в систему (фото, видео, акт передачи объекта в работу, уведомление о начале работ и др.); категории участков по ГОСТ Р 52398-2005; типы и марки смеси а/б; погодные условия; стороны выполнения работ на участке дороги; виды покрытий. Ведение, изменение справочников и наполнение данными должно осуществляться Оператором системы. При необходимости, выявленной в процессе выполнения работ по настоящему ЧТЗ, по заявке Исполнителя Заказчиком должна быть обеспечена настройка необходимых дополнительных справочников средствами П-УНСИ СКДФ. 4.2.3.3 Требования к комплексу «Мобильные интерфейсы СКДФ» Программный комплекс «Мобильные интерфейсы СКДФ» предназначен для обеспечения доступа специалистов, являющихся участниками автоматизируемых процессов, к функциям СКДФ посредством интерфейсов мобильных приложений, устанавливаемых непосредственно на персональные устройства пользователей с учетом задач и потребностей указанной категории пользователей. В целях обеспечения выполнения требований к программному комплексу «Мобильные интерфейсы СКДФ» по назначению, должно быть предусмотрено выполнение следующих прикладных функций и требований: 4.2.3.3.1 Мобильные приложения должны функционировать на смартфонах и планшетных компьютерах с сенсорными экранами 5-7 дюймов, 7-10 дюймов соответственно, на всех поддерживаемых версиях операционных систем (ОС): 60 Android (Phone, Tablet), iOS (iPhone, iPad), если только об ограниченной функциональности на более ранних версиях ОС не сообщено отдельно в описании, должна быть полностью адаптирована под каждую поддерживаемую версию ОС с учетом её особенностей и спецификаций, совместима с сервисами и расширениями платформы, соответствующими целевой функциональности приложения. Мобильное приложение должно корректно работать на последней публичной версии мобильной платформы без неожиданных завершений работы («падений») и ущерба для основной функциональности. 4.2.3.3.2 В составе второй очереди СКДФ Исполнителем должны быть созданы следующие прикладные компоненты СКДФ в объеме требований к их функциям, предъявляемых настоящим Техническим заданием: Мобильное рабочее место (приложение) руководителя (РМ «Руководитель») из состава комплекса «Мобильные интерфейсы СКДФ». Предназначено для обеспечения доступа руководителям дорожной отрасли органов власти субъектов РФ, принимающих участие в реализации проектов в сфере дорожного хозяйства, к функциям СКДФ посредством интерфейсов мобильных приложений, устанавливаемых непосредственно на персональные устройства пользователей с учетом их задач и потребностей. Мобильное рабочее место (приложение) «Пользователь дорог» из состава комплекса «Мобильные интерфейсы СКДФ». МП «Пользователь дорог» предназначено для обеспечения доступа широкого круга пользователей (граждан) к общедоступным функциям и информации в составе СКДФ с персональных мобильных устройств в условиях отсутствия доступа к стационарному рабочему месту. Мобильное рабочее место (приложение) подрядной организации (РМ «Подрядчик»). Предназначено для обеспечения доступа специалистов подрядных организаций, выполняющих работы по обязательствам в сфере дорожной области, к запланированным работам, а также для подтверждения факта выполнения работ посредством интерфейсов мобильных приложений, 61 устанавливаемых непосредственно на персональные устройства пользователей. 4.2.3.3.3. В рамках выполнения первого этапа работ по настоящему Техническому заданию Исполнителем должны быть разработаны и согласованы с Заказчиком частные технические задания на каждое из предусмотренных к разработке мобильных рабочих мест (приложений), содержащие в том числе детализированное описание функциональных возможностей приложений, макеты интерфейсов. 4.2.3.3.1 Требования к РМ «Руководитель» В части РМ «Руководитель» должны быть реализованы прикладные требования к функциям и интерфейсам приложения, описанные ниже. 4.2.3.3.1.1 Общие требования к РМ «Руководитель» РМ «Руководитель» предназначено для обеспечения доступа руководителей высшего и среднего звена (Министр, заместители министра, руководители, кураторы и администраторы проектов, директора департаментов, руководители администраций субъектов Российской Федерации, руководители проектных команд всех уровней, руководители учреждений, участвующих в проектах) к информации, обрабатываемой системой, показателям проектов и документам по проектам в различных формах и представлениях в целях удобного информирования, анализа и поддержки принятия решений. Интерфейс РМ «Руководитель» должен отвечать общим требованиям к эргономике и технической эстетике, предъявляемым к программным средствам подобного класса. Доступ к данным и функциональным возможностям должен обеспечиваться на основании учетной записи пользователя в СКДФ, разделение прав доступа обеспечивается за счет единой ролевой модели системы. В целях обеспечения удобства восприятия информации в приложении должна быть реализована возможность выбора темной или светлой цветовой темы оформления интерфейса. В составе интерфейса РМ «Руководителя» должны быть выделены следующие пользовательские разделы: 62 Рабочий стол; Проекты; Мероприятия; Поручения; Документы. Функционалом приложения должна быть предусмотрена возможность контекстного поиска как по всему массиву информации, доступному пользователю, так и по каждому из разделов приложения. 4.2.3.3.1.2 Требования к пользовательскому разделу «Рабочий стол» Раздел «Рабочий стол» должен формироваться на основании наборов интерактивных виджетов. Виджет должен представлять собой стандартный элемент интерфейса приложения установленного размера и формата, содержащий набор данных, ссылок и функций, сгруппированных по определенному логическому принципу. В рамках приложения должна быть предусмотрена возможность использования, как минимум, следующих типов виджетов: виджет, содержащий информацию по настраиваемому перечню показателей и индикаторов; виджет, отражающий информацию в целом по одному из разделов приложения, как в полном объеме, так и с учетом установленных и сохраненных пользователем параметров фильтрации; виджет, содержащий информацию по конкретному информационному объекту (проект, мероприятие, поручение, документ/протокол); виджет, содержащий информацию по конкретному информационному блоку (разделу) карточки информационного объекта. В части работы с виджетами рабочего стола должно обеспечиваться выполнение следующих функций: настройка перечня показателей, отображаемых в виджете; преднастройка рабочего стола и содержащихся в его составе виджетов в 63 зависимости от уровня и должностных обязанностей пользователя; обеспечение настройки каждого виджета, включая возможности добавления, изменения или удаления показателя; цветовая индикация критичности значения показателя (индикатора) с учетом заданных трендов и характеристик отклонений от пороговых или плановых значений; обеспечение перехода по нажатию на виджет к интерфейсу детализированного представления информации, содержащейся в его составе; возможности добавления виджетов на рабочий стол с использованием отдельной функции в других разделах и представлениях РМ «Руководитель»; сортировка виджетов, содержащихся на рабочем столе пользователя, настройка порядка следования, формирования набора избранных виджетов. 4.2.3.3.1.3 Требование к пользовательскому разделу «Проекты» Пользовательский раздел «Проекты» предназначен для предоставления общей и детальной информации по проектам, находящимся в зоне ответственности пользователя с учетом их иерархии. В составе раздела «Проекты» РМ «Руководитель» должно быть обеспечено выполнение следующих функциональных возможностей: представление перечня доступных пользователю проектов с учетом иерархических взаимосвязей проектов; предоставление в общей информации о проекте как минимум следующих данных: наименование, сроки реализации, куратор, руководитель, администратор; переход к демонстрации подробной информации по каждому проекту из перечня; Сведения, которые как минимум должны содержаться в карточке проекта в составе РМ «Руководитель»: наименование проекта; сроки реализации проекта; 64 участники проекта; риски проекта; показатели проекта; бюджет проекта; задачи, реализуемые в рамках проекта, результаты, контрольные точки проекта; Карточка проекта должна предусматривать следующие функциональные возможности: переход в карточку пользователя; переход в карточку мероприятия; переход в карточку организации; создание поручения по проекту; обеспечение демонстрации сведений по проекту с детализацией «от общего к частному» - от сводного бюджета до информации о контрактах и их исполнении по каждому из мероприятий в рамках контракта; визуализация планов и графиков реализации проектов и мероприятий, включая представление в виде диаграммы Ганта; просмотр сведений о фактических значениях показателей по проекту, включая оперативные данные по контрольным точкам проекта; графическая визуализация плановых и фактических значений показателей в различных формах, включая возможность просмотра изменения показателей в динамике; отображение цветовой индикации, соответствующей следующим статусам реализации проектов: зеленый индикатор - отсутствие отклонений, проблемы и риски отсутствуют, дополнительные решения не требуются; желтый индикатор - наличие некритических отклонений, выявлены проблемы и риски, решение которых находится в зоне полномочий руководителя проекта; красный индикатор - наличие критических отклонений, выявлены проблемы и риски, решение которых находится вне зоны полномочий 65 руководителя проекта; серый индикатор - сведения не представлены, при этом в случае, если статус носит прогнозный характер, соответствующий цветовой индикатор должен указываться в заштрихованном виде в соответствующей цветовой индикации; возможность формирования и добавления на рабочий стол пользователя виджетов с показателями проектов различной детализации и разрезов. Должна быть реализована возможность создания виджета, содержащего статус реализации проекта с указанием цветовой индикации, характеризующей информацию о реализации проекта в разрезе рисков, показателей, бюджета, результатов, задач и контрольных точек. 4.2.3.3.1.4 Требования к пользовательскому разделу «Мероприятия» Пользовательский раздел «Мероприятия» предназначен для предоставления общей и детальной информации о мероприятиях, реализуемых в рамках проектной деятельности и находящихся в зоне ответственности пользователя. В составе раздела «Мероприятия» РМ «Руководитель» должно быть обеспечено выполнение следующих функциональных возможностей: просмотр перечня мероприятий с возможностью фильтрации по основным параметрам; предоставление в общей информации о мероприятии как минимум следующих данных: наименование, сроки реализации, статус; переход к демонстрации подробной информации по каждому мероприятию из перечня; Сведения, которые как минимум должны содержаться в карточке мероприятия в составе РМ «Руководитель»: наименование мероприятия; сроки реализации мероприятия; статус мероприятия; регион мероприятия; уровень мероприятия; 66 проект, в рамках которого проводится мероприятие; заказчик мероприятия; сведения о стоимости и мощности работ, об объекте, на котором выполняются работы; сведений о плановых и фактических показателях по мероприятию, включая финансирование, контрактацию, этапность работ, сведения об актах и платежах; Карточка мероприятия должна предусматривать следующие функциональные возможности: переход в карточку пользователя из карточки мероприятия; переход в карточку проекта из карточки мероприятия; переход в карточку контракта из карточки мероприятия; переход в карточку организации из карточки мероприятия; возможность просмотра объектов выполнения работ в картографическом представлении; обеспечения возможности создания виджетов для раздела «Рабочий стол» с различной детализацией и формой представления информации. 4.2.3.3.1.5 Требования к пользовательскому разделу «Поручения» Пользовательский раздел «Поручения» предназначен для работы пользователя с задачами и поручениями, постановка которых осуществляется в рамках проектной деятельности и находится в зоне ответственности пользователя. В составе раздела «Поручения» РМ «Руководитель» должно быть обеспечено выполнение следующих функциональных возможностей: просмотр перечня поручений (задач), доступных пользователю с обеспечением возможности сортировки и фильтрации, в том числе по статусу поручения, роли пользователя; переход к демонстрации подробной информации по каждой задаче из перечня; обеспечение возможности работы 67 с задачей, включая функции делегирования, принятия в работы, выполнения с отчетом, проверке задачи, переноса срока, прерывания и возобновления задачи; создание поручения; предоставление в общей информации о поручении как минимум следующих данных: наименование, сроки, регистрационный номер; Сведения, которые как минимум должны содержаться в карточке задачи в составе РМ «Руководитель»: наименование задачи; регистрационный номер задачи в системе; описание задачи; срок выполнения задачи; сведения об авторе, исполнителе, контролере и наблюдателях по задаче; вид задачи; наименование проекта, в рамках которого поставлена задача; информация об отчете по задаче и его статусе. Карточка задачи должна предусматривать следующие функциональные возможности в зависимости от прав доступа пользователя в рамках задачи: редактирование задачи; делегирование задачи; принятие задачи в работу; выполнение задачи; проверка отчета по задаче; запроса переноса срока по задаче; переход в карточку пользователя; переход в карточку проекта; создание виджетов для раздела «Рабочий стол» на основании информации, содержащейся в разделе с различной степенью детализации и характером информации. 68 4.2.3.3.1.6 Требования к пользовательскому разделу «Документы» Пользовательский раздел «Документы» предназначен для обеспечения доступа пользователя к осуществления архиву документов проектной и деятельности протоколов, (письма, продуцируемых уведомления, в ходе телеграммы, протоколы и др.). В составе раздела «Документы» РМ «Руководитель» должно быть обеспечено выполнение следующих функциональных возможностей: просмотр перечня документов и протоколов проектной деятельности, с возможностью сортировки и фильтрации по статусам, типам, дате документа и другим ключевым параметрам; переход к демонстрации подробной информации по каждому документу или протоколу из перечня; предоставление в общей информации о документе или протоколе как минимум следующих данных: наименование, регистрационный номер, дата регистрации; Карточка документа РМ «Руководитель» должна отображать как минимум следующие сведения: наименование документа; описание документа; автора документа; подписант документа; регистрационный номер; дата регистрации документа; тип документа; наименование проекта, в рамках которого документ создан; сведения о процессе, который запущен в рамках документа. Функциональные возможности, которые должна обеспечивать документа в зависимости от прав доступа пользователя к документу: редактирование документа; 69 карточка ознакомление/согласование документа; переход в карточку проекта; переход в карточку пользователя; создания поручения в привязке к конкретному документу или протокольному решению; формирования виджетов для отображения в разделе «Рабочий стол». Карточка протокола РМ «Руководитель» должна отображать как минимум следующие сведения: наименование протокола; регистрационный номер протокола; дата протокола; тип протокола; наименование проекта, в рамках которого протокол создан; сведения о протокольных решениях. Функциональные возможности, которые должна обеспечивать карточка документа в зависимости от прав доступа пользователя к документу: редактирование протокола; выполнение протокольных решений; переход в карточку проекта; переход в карточку пользователя; создания поручения в привязке к конкретному протокольному решению; формирования виджетов для отображения в разделе «Рабочий стол». 4.2.3.3.1.7 Дополнительные требования К основным пользовательским разделам приложения должна быть предусмотрена функция предоставления доступа к контактной информации участников процессов в рамках автоматизируемой СКДФ деятельности, информация об организациях, в которых работают пользователи и подробная информация о контракте, в рамках которого проводятся работы мероприятия. 70 4.2.3.3.2 Требования к МП «Пользователь дорог» В части МП «Пользователь дорог» должны быть реализованы следующие прикладные требования к функциям и интерфейсам приложения: 4.2.3.3.2.1 Общие требования к МП «Пользователь дорог» МП «Пользователь дорог» предназначено для обеспечения доступа широкого круга пользователей (граждан) к общедоступным функциям и информации в составе СКДФ с персональных мобильных устройств в условиях отсутствия доступа к стационарному рабочему месту. Интерфейс МП «Пользователь дорог» должен отвечать общим требованиям к эргономике и технической эстетике, предъявляемым к программным средствам подобного класса. Доступ к данным и функциональным возможностям должен обеспечиваться с использованием пары логин/пароль, получаемой гражданином после прохождения процедуры регистрации в СКДФ, либо с помощью авторизации с учетной записью Единой системы идентификации и аутентификации (ЕСИА). В целях обеспечения удобства восприятия информации в приложении должна быть реализована возможность выбора темной или светлой цветовой темы оформления интерфейса. В составе интерфейса МП «Пользователь дорог» должны быть выделены следующие пользовательские разделы: Личный кабинет; Карта; Сообщения. 4.2.3.3.2.2 Требования к пользовательскому разделу «Личный кабинет» Пользовательский раздел «Личный кабинет» предназначен для обеспечения просмотра и управления контактными и учетными данными пользователя, просмотра общей информации о работе с системой. В составе раздела «Личный кабинет» МП «Пользователь дорог» должно быть обеспечено выполнение следующих функциональных возможностей: 71 просмотр и изменение общей информации и учетных данных пользователя; просмотр сводной статистики работы пользователя с системой; просмотр перечня уведомлений об изменении статусов сообщений пользователя с возможностью перехода в карточку сообщения при нажатии на соответствующее уведомление; просмотр списка «избранное», содержащего перечень объектов (дорог, участков проведения дорожных работ), которым пользователем была проставлена отметка «в избранное» с возможностью просмотра карточки такого объекта, отображения его на карте. 4.2.3.3.2.3 Требования к пользовательскому разделу «Карта» Пользовательский раздел «Карта» предназначен для обеспечения просмотра на картографической основе сведений о дорожных объектах и участках проведения работ, отправке сообщений о состоянии дорожной сети в привязке к местности и конкретному объекту. В составе раздела «Карта» МП «Пользователь дорог» должно быть обеспечено выполнение следующих функциональных возможностей: определение местонахождения пользователя и позиционирования интерфейса раздела в соответствии с координатами, полученными с мобильного устройства пользователя; в случае отсутствия возможности использования функции определения геокоординат мобильного устройства пользователя, позиционирование должно осуществляться на основании определения IP-адреса пользователя и/или с учетом сведений, указанных в учетных данных пользователя; отображение дорожных объектов и участков проведения работ с возможностью фильтрации по типам объектов и параметров, просмотра карточки объекта (участка), содержащей детальную информацию об объекте или участке; обеспечение возможности создания и отправки сообщения о состоянии дорожной сети пользователем. 72 При этом должна обеспечиваться возможность создания сообщения как путем установки геометки пользователем на карте с последующим определением принадлежности сообщения средствами прикладного ПО СКДФ, так из карточки объекта или мероприятия с обеспечением привязке сообщения к данному зоне поиска, объекту/мероприятию; обеспечения возможности просмотра сообщений в отправленных другими пользователями с указанием типа сообщения, его описания, статуса и другой атрибутивной информации; при создании сообщения должна быть предусмотрена возможность заполнения карточки сообщения с индикацией обязательных полей, возможностью выбора заполнения справочных полей из выпадающих списков. Перечень справочных и обязательных полей, а также типов их значений определяется Исполнителем и согласовывается с Заказчиком в ходе выполнения работ; в процессе создания сообщения пользователю должна быть доступна возможность приложить к сообщению фотоматериалы, подтверждающие или дополняющие информацию, представленную в сообщении; создание фотографий, прикладываемых к сообщению, должно осуществляться непосредственно из интерфейса МП «Пользователь дорог» без использования возможности добавления фотографий из галереи на устройстве пользователя. При этом должен осуществляться контроль соответствия геометки на фотографии с местом установки геометки сообщения или координатами объекта, к которому оно относится. 4.2.3.3.2.4 Требования к пользовательскому разделу «Сообщения» Пользовательский раздел «Сообщения» предназначен для обеспечения возможности отслеживания пользователем хода и результатов рассмотрения отправленных им сообщений. В составе раздела «Сообщения» МП «Пользователь дорог» должно быть обеспечено выполнение следующих функциональных возможностей: 73 Просмотр перечня сообщений, отправленных пользователем с указанием основной информации о нем (как минимум: дата и время отправки, тип сообщения, статус); Фильтрация сообщений по набору параметров; Просмотр карточки сообщения, содержащий детальную информацию о сообщении, статусе и результатах его рассмотрения; Обеспечение возможности работы с сообщением в соответствии с регламентом, включая подтверждение отчета о рассмотрении сообщения, комментирование и прочее. Описание процесса и регламент обработки сообщений должен быть разработан Исполнителем и согласован с Заказчиком в ходе выполнения работ в рамках создания компонента «Система обеспечения ведения цифровой базы дорожных объектов, программ и результатов дорожных работ», предусматривающего автоматизацию соответствующих процессов. 4.2.3.3.3 Требования к РМ «Подрядчик» Мобильное рабочее место подрядной организации (РМ «Подрядчик») должно предоставлять возможность специалистам подрядной организации подтверждать выполненные работы по контрактам в сфере дорожного хозяйства при помощи мобильного приложения. Мобильное приложение должно функционировать на смартфонах с сенсорными экранами 5-7 дюймов, на всех поддерживаемых версиях операционной системы (ОС) Android (Phone). Интерфейс РМ «Подрядчик» должен отвечать общим требованиям к эргономике и технической эстетике, предъявляемым к программным средствам подобного класса. Доступ к данным и функциональным возможностям должен обеспечиваться на основании учетной записи пользователя в СКДФ, разделение прав доступа обеспечивается за счет единой ролевой модели системы. В целях обеспечения удобства восприятия информации в приложении должна быть реализована возможность выбора темной или светлой цветовой темы оформления интерфейса. 74 В части РМ «Подрядчик» должны быть реализованы следующие прикладные требования к функциям и интерфейсам приложения: В рамках реализации РМ «Подрядчик» должно быть обеспечено решение следующих задач: 1. подтверждение выполнения точечных заданий по содержанию дорожных объектов (в т.ч. ямочный ремонт); 2. подтверждение выполнения заданий по линейным работам по содержанию дорожных объектов; 3. подтверждение выполнения работ, запланированных на основании обращений граждан; 4. выполнение работ по ремонту дорожных объектов; 5. выполнение работ по строительству, реконструкции, капитальному ремонту дорожных объектов; 6. push-уведомления. В рамках выполнения работ по реализации выполнения заданий по точечным работам по содержанию дорожных объектов (в т.ч. по ямочному ремонту) должны быть реализованы следующие возможности: отображение перечня запланированных заданий в рамках организации; фотофиксация техники с геометкой, датой и временем выполнения (при необходимости); фиксация гос. номера техники (при необходимости); фотофиксация выполненных работ (до/после/в процессе) с возможностью привязки объема и вида выполненной работы и отметкой геолокации, даты/времени выполнения и места производства работ; передача сведений о результатах работы в Портал подрядной организации. В рамках выполнения работ по реализации выполнения заданий по линейным работам по содержанию дорожных объектов должны быть реализованы следующие возможности: отображение перечня запланированных заданий в рамках организации; 75 фотофиксация техники с геометкой, датой и временем выполнения; фиксация гос. номера техники; запись трека движения транспортного средства исполнителя; передача сведений о результатах работы в Портал подрядчика. В рамках выполнения работ по реализации выполнения заданий по ремонту дорожных объектов должны быть реализованы следующие возможности: отображение перечня запланированных заданий в рамках организации (участки ремонта); фотофиксация выполненных работ (до/после/в процессе) с возможностью привязки объема и вида выполненной работы и отметкой геолокации, даты/времени выполнения и места производства работ; внесение сведений о выполнении работы. В зависимости от выбранного вида работы должен быть доступен соответствующий набор атрибутов для ввода: o общие атрибуты для всех работ по ремонту: o объем работ; o единица измерения объема работ; o пикетаж (начало участка); o пикетаж (конец участка); o сторона участка дороги (право, лево); o причина отставания от графика; o признак последней работы данного вида (обозначает завершение этапа ремонта); o погодные условия при выполнении работ; o перечень дополнительных атрибутов асфальтобетонной смеси: o температура воздуха, °; o тип и марка а/б смеси; o температура смеси, ˚; o расход смеси на нижний слой, т; 76 для работ по укладке o расход смеси на верхний слой, т; o брак смеси, т; o марка и вес катка; o количество катков; передача сведений о результатах работы в Портал подрядной организации. Все фотоматериалы, получаемые через РМ «Подрядчик», должны обладать специализированным штампом, отображающим информацию о местоположении, координатах, дате и времени создания фотоматериала. 4.2.3.4 Требования к программному обеспечению подсистемы обеспечения функционирования, поддержки пользователей и эксплуатации программно-технических средств (П-ОФП) второй очереди СКДФ Подсистема П-ОФП второй очереди предназначена для обеспечения процессов поддержки пользователей СКДФ и мониторинга функционирования инфраструктуры. Системы и должна обеспечивать выполнение функций, представленных ниже. Реализации функций разрабатываемого программного обеспечения описного в разделе 4.2.3.4.1. Реализации функции закупаемого программного обеспечения описного в разделах 4.2.3.4.2, 4.2.3.4.4. Создание сценария обработки обращений и доработки и сопровождений дынных и функций, описанных в разделах 4.2.3.4.3. Мониторинг производительности компонентов и сервисов СКДФ 4.2.3.4.1 4.2.3.4.1.1 Общие требования В части мониторинга производительности компонентов инфраструктуры и сервисов СКДФ, П-ОФП СКДФ должна обеспечивать: разграничение зоны ответственности за качество контролируемых каналов связи СКДФ с поставщиком услуг связи за счет поддержки аппаратных измерительных средств, устанавливаемых в разрыв соединения; управление качеством контролируемых каналов связи на уровне контрактов 77 SLA (соглашение об уровне сервиса); возможность мониторинга сквозного качества канала связи (end-to-end) путем пропуска контрольного трафика с заданными параметрами через исследуемый сегмент сети; отсутствие воздействия тестового траффика на качество пользовательской услуги (создание нагрузки тестовым трафиком при непрерывном измерении одного направления не более 5кбит/сек); поддержку следующих протоколов для непрерывного и нагрузочного измерения показателей качества: o ICMP; o UPD; o TCP; o HTTP: o TWAMP (RFC 5357); o Ethernet (L2); непрерывный контроль ключевых качественных характеристик предоставляемого канала связи (KPI): o процент потерянных пакетов (по направлениям), %; o односторонняя и круговая сетевая задержка, мс; o колебания односторонней и круговой сетевой задержки (джиттер), мс; o максимальная пропускная способность канала связи, КБит/сек; o объем передаваемого трафика, Кбайт; o текущая загрузка канала, КБит/сек; o коэффициент загрузки канала, %; непрерывный контроль ключевых показателей производительности комонентов системы СКДФ (KPI): o процент доступности сервиса/компонента, %; o время отклика, мс; o колебания времени отклика (джиттер), мс; 78 o время разрешения доменного имени узла, мс; o время выполнения сложного сценария (авторизация, поиск и д.р.), мс; o процент загрузки элемента инфраструктуры СКДФ (сервер, АРМ и т.д.): CPU, RAM, HDD, %; формирование периодической отчетности SLA по всем типам контролируемых компонентов и сервисов СКДФ; возможность сбора информации следующих источников: o аппаратных измерительных зондов с поддержкой протоколов непрерывного контроля IP-соединения ICMP, UDP, TWAMP и возможностью установки в разрыв соединения; o сетевого оборудование со встроенными механизмами оценки качества канала связи Cisco IP SLA; o программных агентов для ОС Windows, Linux; поддержка измерительных средств с функцией автоматического заведения в систему (Plug&Play); автоматическое определение типа подключаемого поддерживаемого измерительного устройства по протоколу SNMP; гибкое управление большими списками объектов с применением поиска и сложных фильтров (фильтрация, сортировка в прямом и обратном направлении на всех страницах со списками записей, полнотекстовый поиск, метки объектов) и назначения меток (тегов) объектам. 4.2.3.4.1.2 Требования к мониторингу услуг В части мониторинга производительности контролируемых компонентов и сервисов СКДФ П-ОФП СКДФ должна обеспечивать: сбор результатов непрерывных измерений производительности контролируемых компонентов и сервисов СКДФ в режиме псевдо-реального времени (агрегация и обновление данных каждые 5 минут); возможность измерения показателей производительности канала связи с точностью не менее (0,05% потери макетов, 1 мкс для задержки и джиттера) 79 с применением аппаратных зондов; возможность мониторинга показателей производительности контролируемых компонентов и сервисов СКДФ в режиме «реального времени» с частотой обновления данных по показателям качества услуги не реже чем раз в 10 секунд; оценку состояния контролируемых компонентов и сервисов СКДФ путем сравнения полученных показателей производительности с установленными для них пороговыми значениями согласно SLA/OLA; дифференциацию состояний контролируемых компонентов и сервисов СКДФ по цветовым кодам (Красный - отказ услуги, Желтый - Деградация качества услуги, Зеленый - норма, Черный - отсутствие данных от источника); визуализацию результатов измерений качественных характеристик компонентов и сервисов СКДФ с использованием масштабируемых по оси времени линейных (информационных и блоков) логарифмических информационной графиков панели, и виджетов содержащих столбчатые и круговые диаграммы; корреляцию истории изменения нескольких показателей производительности контролируемых компонентов и сервисов СКДФ в рамках одного графика c возможностью оперативного управления набором отображаемых линий показателей; корреляцию качества контролируемых компонентов и сервисов СКДФ и элементов сетевой топологии (коммутаторы, маршрутизаторы, сервера, АРМ пользователей) с возможностью автоматического поиска сетевых элементов и ручной правки связей между элементами топологии; возможность проведения нагрузочного тестирования каналов связи с целью оценки пропускной способности на следующих уровнях: o Ethernet (L2); o UDP (L4); 80 o TCP (L4); возможности оценки максимального размера пропускаемых на сегменте сети UDP пакетов (MTU); возможность задания расписания выполнения нагрузочных тестов для группы каналов связи с применением компонента календаря; экспорт результатов нагрузочного тестирования в формате PDF для предоставления внешним контрагентам; отображение тепловой карты производительности компонентов и сервисов СКДФ по регионам РФ; отображение всех типов контролируемых компонентов и сервисов СКДФ на географической карте в привязке к координатам точек доступа, детализация координат в формате Страна/Область/Город/Улица/Дом/Этаж/Квартира; мониторинг сервисов СКДФ прикладного уровня (WEB-порталы, базы данных, WEB-сервисы (REST, SOAP и т.д.) путем имитации действий реальных пользователей (авторизация на портале, введение и анализ поисковых запросов, выполнение SQL транзакций и т.д.); сбор статистики пользовательского трафика NetFlow или аналогичного DPI протокола; анализ пользовательского трафика с отображением в виде круговых диаграмм и таблица распределения трафика в разрезе протоколов, приложений, пользователей и IP адресов. 4.2.3.4.1.3 Требования к отчетности В части формирования отчетности SLA П-ОФП СКДФ должна обеспечивать: оценку соответствия всех типов контролируемых компонентов и сервисов СКДФ уровню обслуживания SLA посредством предоставления отчетов SLA за различные периоды времени (час, сутки, неделя, месяц, квартал); учет режима функционирования компонентов и сервисов СКДФ (24х8, 5х8) с возможностью гибкой настройки бизнес часов, вне которых нарушения SLA не считаются; 81 набор преднастроенных типовых политик качества (спецификаций SLA) содержащих наборы контролируемых показателей производительности компонентов и сервисов СКДФ и правила их оценки; формировать перечень ключевых событий за период в отчетах SLA: количество отказов компонентов и сервисов СКДФ, проводимые плановопрофилактические работы и периоды исключений из отчетов SLA, а также суммарное время каждого типа событий (KQI); возможность учета и управления периодами для проведения плановых и профилактических работ на сети (нарушения в работе компонентов и сервисов СКДФ за установленный период плановой работы в отчетах SLA и оповещениях учитываться не должны); возможность исключать определенные интервалы из отчета SLA за текущий период после формирования отчета, а также предоставлять возможность повторно рассчитать отчет с учетом созданных исключений; возможность создания условий для автоматического исключения нарушений из отчетов SLA, например, по причине 100% утилизации контролируемого канала связи; возможность экспорта отчета SLA в печатную форму документа WORD, PDF, EXCEL; формирование печатной формы отчета SLA за произвольный промежуток интервал дней по произвольному набору компонентов и сервисов СКДФ; автоматическую рассылку печатных форм опубликованных отчетов SLA средствами электронной почты. 4.2.3.4.2 Работа с запросами, авариями, повреждениями, планово- профилактическими работами 1) Регистрация запросов В части регистрации запросов пользователей СКДФ П-ОФП СКДФ должна обеспечивать: 82 единую точку приема и регистрации всех Запросов и обращений клиентов, связанных с использованием услуг (далее Запросов) в единой базе данных хранящей всю оперативную информацию по ним регистрацию запроса оператором с помощью web-приложения (тонкого клиента) отображение оператору в момент регистрации информации об уже открытых запросах данного клиента автоматическую регистрацию запросов при помощи электронных писем, которые приходят в назначаемые почтовые ящики. Адреса назначаемых почтовых ящиков задаются в настройках системы собственный Webинтерфейс и средства интеграции с внешним личным кабинетом для предоставления клиентам возможностей по регистрации запросов просмотра информации по своим запросам категорирование, и определение других необходимых параметров, обеспечивающих управление Запросами, в частности: o влияние; o срочность; o приоритет; o уровень обслуживания; o регламентный срок разрешения Запроса; обеспечивать возможность гибким образом настраивать форму обработки обращения (набор полей) и указывать правила заполнения данных полей возможность прикрепить к запросу файлы в текстовом и графическом форматах 2) Обработка запросов В части обработки запросов пользователей СКДФ П-ОФП СКДФ должна обеспечивать: средства для внесения дополнительной информации и изменения приоритета Запроса на протяжении всего жизненного цикла Запроса (после его 83 первичной регистрации до момента закрытия); ручную передачу инцидента для его решения на специализированные линии поддержки (в функциональные подразделения) ответственные за поддержку и предоставление соответствующей услуг; возможность автоматической передачи инцидента для его решения на специализированные линии поддержки (в функциональные подразделения) ответственные за поддержку и предоставление соответствующей услуг; предоставление информации об уже имеющихся Запросах, известных проблемах, которые подобны (аналогичны) поступившему и способах их решения; отслеживание детальной истории событий по каждому Запросу; возможность прикрепить к существующему запросу файлы в текстовом и графическом форматах; возможность автоматической смены состояния (статуса) по истечению указанного времени; ведение списка комментариев по запросу; учет зависимостей между запросами. 1.1. Закрытие запросов В части закрытия запросов пользователей СКДФ П-ОФП СКДФ должна обеспечивать: обеспечивать возможность ввода описания решения: o ввод подтверждения устранения запроса от клиента; o ввод описания с помощью добавления текста; o выбора описания результата решения из списка описаний типичных решений; автоматическое оповещение пользователей о завершении обработки их обращений с возможностью подтвердить или опровергнуть успешность решения непосредственно по электронной почте 1.2. Отслеживание регламентов исполнения запросов 84 В части отслеживания регламентов исполнения запросов пользователей СКДФ ПОФП СКДФ должна обеспечивать: обслуживание запросов, определение максимального времени устранения запроса с учетом приоритета обратившегося пользователя или затронутой услуги; контроль времени начала и завершения работ по каждому запросу и по каждой активности в рамках работы над Запросом; учет общего времени обработки запроса в службе поддержки; учет времени обработки в каждом из состояний и каждым из ответственных; контроль превышения нормативного времени, выделенного на устранение запроса; рассылку уведомлений в соответствии со сделанными настройками (по событиям, по регламентным срокам) по e-mail. 1.3. Настройка workflow (процесса прохождения) запросов В части настройки процесса прохождения (workflow) запросов пользователей СКДФ П-ОФП СКДФ должна обеспечивать: поддержку различных типов запросов, каждый из которых определяет маршрут обработки, перечень ответственных сотрудников и подразделений (workflow); назначение запросов в работу на группу специалистов; назначение запросов в работу персонально; настройку списка задач, из которых складывается выполнение запросов. У каждой задачи должно быть свое workflow; учет общего времени работы над запросом; учет времени выполнения запроса каждым специалистом, который принимал участие в ее решении; возможность настройки функциональной и административной эскалации запроса в соответствии с настроенными условиями эскалации. 1.4. Работа с авариями и повреждениями 85 В части работы с авариями и повреждениями компонентов и сервисов СКДФ ПОФП СКДФ должна обеспечивать: регистрацию аварий и повреждений в виде паспортов неисправностей с присвоением уникального идентификатора; возможность специалисту установить связь между запросами пользователей и паспортами неисправностей; возможность учета заявленных и выявленных неисправностей, а также их классификацию по критериям: технологическое оборудование сети, уровень сети, технология, тип оборудования, оборудование, модуль; возможность учитывать первичные и дублирующие паспорта неисправностей, а также привязки дублирующего паспорта неисправности к первичному. 1.5. Работа с планово-профилактическими работами В части работы с планово-профилактическими работами, затрагивающими компоненты и сервисы СКДФ, П-ОФП СКДФ должна обеспечивать: регистрацию планово-профилактических работ с присвоением уникального идентификатора; возможность специалисту установить связь между запросами пользователей и планово-профилактическими работами; возможность учета планируемого и фактического времени выполнения планово-профилактических работ, а также их классификацию по критериям: технологическое оборудование сети, уровень сети, технология, тип оборудования, оборудование, модуль. 1.6. Подсистема подготовки отчетности по инцидентам и неисправностям В части подготовки отчетности по инцидентам и неисправностям компонентов и сервисов СКДФ П-ОФП СКДФ должна обеспечивать: функции контроля, накапливая информацию о бизнес-процессах: как часто они запускаются, сколько времени занимает их выполнение, как загружены сотрудники и т.д., предоставляя 86 в графической форме динамику соответствующих показателей. базовый набор отчетов по показателям бизнес-процессов, на основе которых конструируются ключевые показатели эффективности (KPI). возможность расширение списка отчётов как по имеющимся, так и вновь создаваемым компонентам и серисам СКДФ, за счет подгрузки новых заранее подготовленных шаблонов отчетов. построения отчетов, отражающих значения KPI процессов на текущий момент или за период. формирование отчетов по расписанию. сохранение отчета в файлы офисного формата (MS Office, Open Office, csv, txt) графическое представление данных в отчете (в виде диаграмм). формирование печатных форм объектов в форматах html, doc. 4.2.3.4.3 Приём и Обработка входящих коммуникаций в голосовом и текстовом каналах 4.2.3.4.3.1 Общие Требования В части обработки поступающих обращений по средствам голосовых и текстовых каналов сервисов СКДФ, П-ОФП СКДФ должна обеспечивать: Прием обращений в голосовом и текстовом каналах Обработки голосовых вызовов по средствам IVR Ведение записи голосовых и текстовых обращений Звукозапись вызовов; АРМ оператора и супервизора; Отчетный модуль. 87 4.2.3.4.3.2 Требования к приему обращений в голосовом и текстовом каналах В частности, приёма обращений в голосовом и текстовых каналах в СКДФ ПОФП СКДФ должна обеспечивать: Прием обращений из голосового канала (по протоколу SIP); Прием обращений в текстовом канале: электронная почта Гибкую настройку маршрутизации поступающих обращений на основе метаинформации об обращениях; Запуск сценария определения тематики обращения; Запуск сценария обработки обращения по определенной ранее теме; Перевода обращения между различными очередями обращений (например, между уровнями обслуживания); Организация очередей обслуживания обращений, правила выбора обращения при освобождении оператора, правила выбора оператора при поступлении обращения; Интеграции с подсистемами распознавания и синтеза речи по протоколу MRCP (v.1). 4.2.3.4.3.3 Требование к обработке голосовых вызовов по средствам IVR В частности, обработки голосовых вызовов в IVR СКДФ П-ОФП СКДФ должна обеспечивать: Формирование и имплементации логики IVR обработки обращений; Воспроизведение звуковых сообщений из пред записанными звуковыми файлами; Выдачу голосовых сообщений или выбор меню для пользователей; 88 Реакции на выбор пользователей пунктов меню или тем обращений; Прием и обработку сигналов тонового набора (DTMF); Маршрутизацию вызовов, как по выбору пользователей, так и при отсутствии такового; Предоставление функциональности синтеза и распознавания речи по стандартному протоколу MRCP (v. 1); Формирование и воспроизведение динамических голосовых сообщений с использованием функциональности синтеза речи при взаимодействии с сервисом интерактивного текстового взаимодействия; Возможность изменения меню, сценариев голосового взаимодействия и размещения голосовых файлов в режиме онлайн без приостановления действия текущих сценариев; Настраиваемые параметры Уровня уверенности распознавания, таймауты, Barge-in на каждом шаге. Повторить озвученное сообщение в случае, если клиент просит повторить или говорит, что не слышит или не понимает заданное количество раз. Позволять Абоненту получить персонифицированную информацию только после авторизации. Согласно сценарию голосового сервиса уметь формировать фразы, соответствующие логике диалога такие как подсказки, результат не распознавания, уточняющие вопросы, просьба перефразировать запрос, Автоматически переводить звонок на оператора в следующих случаях заданной логики маршрутизации на операторов, невозможности понять причину обращения, после трех отклоненных абонентом подтверждений, отсутствия информации иных причинах, невозможности верифицировать пользователя, если в запросе пользователей содержится просьба о таком переводе, например, молчания абонента (более заданного количества попыток), невозможности распознать высказывания абонента (низкая уверенность распознавания или высокий уровень шумов) или однозначно 89 отнести (не полностью сформулированного голосового запроса) к той или иной теме (более 3х попыток), ошибок работы системы, в том числе из-за превышения времени ответа веб-сервисов перевод вызова на оператора направлять распознанный текст, определенную тематику, идентификатор абонента с помощью оговоренных с Заказчиком способов (AIC, CTI, поле user-to-user, др.), а также использовать варианты перевода вызовов (трансфер): bridge (мост), consult (с консультацией), blind (слепой). 4.2.3.4.3.4 Требования к записи разговоров В частности, записи разговоров СКДФ П-ОФП СКДФ должна обеспечивать Запись в стерео-режиме и хранение всех вызовов, при необходимости должна быть возможность выборочной записи: Запись без телефонных гудков. Отключение записи при нахождении в режиме атематической обработки. При постановке вызова на удержание. отключения звукозаписи в ходе разговора. архивирования и скачивание записей. 4.2.3.4.3.5 Требования к АРМ оператора и супервизора Программное обеспечение, с помощью которого производится обработка обращений, должно быть построено на базе клиент-серверных технологий с обеспечением веб-интерфейса для работы пользователей под управлением ОС семейств MS Windows и Linux: Microsoft Windows не ниже версии 8.0; Linux Ubuntu 12.04 и 14.04 для 64-битной архитектуры; Система должна корректно функционировать в следующих браузерах: 90 Microsoft Internet Explorer версии не ниже 11.0; Google Chrome не ниже 46.0. Программное обеспечение оператора должно предусматривать возможность добавления неограниченного набора дополнительных состояний, таких как: «Обед», «Обучение», «Вызов к руководству» и другие. программное обеспечение оператора должно автоматически изменять статус оператора при блокировке им компьютера или включении заставки экрана. Интерфейс программного обеспечения оператора должен включать в себя как минимум следующие управляющие элементы: Окно управления обращениями; Окно со скриптом разговора оператора; Окно внутреннего чата; Кнопка запроса помощи у супервизора; Панель личных показателей оператора; Панель контактов. Программный телефон оператора должен предоставлять оператору следующие возможности: Отображать сценарии разговора оператора (скрипт разговора должен определяться очередью, из которой распределено обращение), обладающих следующими функциями: Подсказки и статьи Базы знаний, связанные с текущим этапом разговора. Возможность категоризации обращения для последующей аналитики. Возможность фиксации неограниченного настроенного набора параметров для статистики и передачи в сторонние системы. Отображение в сценарии разговора следующей информации: идентификатор пользователя и название канала связи, на который пришло обращение; информация об абоненте, если он идентифицирован; возможность поиска информации об абоненте по озвученным им данным; 91 история обращений пользователя. −Предоставлять возможность текстового взаимодействия с другими пользователям. В случае возникновения необходимости операторы должны иметь возможность запрашивать помощь у супервизора. Если оператор не ответил на поступившее обращение, то во избежание повторного не ответа, рабочее место оператора должно автоматически переводиться в нерабочий режим до тех пор, пока не вернется оператор и не перейдет в режим готовности. Система должна предусматривать соответствующее оповещение супервизора о каждом случае не ответа оператора на обращение. Помимо оповещения в реальном времени, Система должна формировать соответствующие хронологические отчеты с указанием времени и имени оператора, не ответившего на обращение. Программное обеспечение супервизора должно обеспечивать все требования к клиентскому программному обеспечению оператора и обеспечивать дополнительный объем функций: наблюдение за статусом каждого оператора (статус и длительность нахождения в нем); отстранение оператора от работы; ответ на запрос о помощи оператора и отмена запроса помощи; посылать текстовые сообщения на компьютеры операторов (лично и массово); просмотр экранов операторов в режиме реального времени 4.2.3.4.3.6 Отчетности Требования к Отчётности должна позволять собирать, обрабатывать и агрегировать статистические данные обо всех взаимодействиях с клиентами независимо от канала взаимодействия, площадки, на которой обрабатывалось обращение в случае распределенной структуры контактного центра. 92 Статистика должна храниться в реляционной базе данных. В Системе должна быть реализована возможность построения статистических отчетов. В подсистеме должна быть реализована возможность создания отчетов различной сложности, позволяющих пользователю сформировать полноценное представление о деятельности. Пользовательский отчет должен генерироваться в табличной форме на основе заранее созданного шаблона отчета, в котором должна содержаться информация о способе построения отчетов, сведениях, включаемых в отчет, фильтрах и другой необходимой информации. Подсистема должна предоставлять набор стандартных отчетов в базовой поставке. Подсистема отчётности должна позволять строить хронологические отчёты и отчёты реального времени. Должна быть предусмотрена возможность обновления отчетов реального времени — не реже, чем раз в 5 секунд. С помощью этих отчетов супервизоры и менеджеры должны иметь возможность принимать оперативные решения по управлению контактным центром. Должна быть предусмотрена возможность обновления хронологических отчетов не реже чем через 10 минут. Должен быть предусмотрен пользовательский графический веб-интерфейс, с возможностью настройки, конфигурирования, построения исторических отчетов и их выгрузки. Должна быть предусмотрена возможность одновременного доступа к средствам отчетности и администрирования сразу нескольких авторизованных пользователей с разным уровнем доступа. Должна быть предусмотрена возможность сбора статистической информации о вызовах, получивших принудительные отбой или сигнал «занято». Вся структура хранения данных должна быть формализована и описана на русском языке. 93 Система должна вести статистическую информацию о событиях, которые в ней происходят. Отчёты должны генерироваться в табличной форме на основе заранее созданного шаблона отчета, в котором должна содержаться информация о том, как должен строиться отчет, какие сведения в него включать, какие фильтры должен содержать и пр. Шаблон отчета должен создаваться на основании SQL-источника – это базовый механизм, позволяющий использовать результаты выполнения SQL-запроса в качестве данных для отчета. Система должна позволять выполнять следующие действия по настройке отображения отчета: настройка отображения полей отчета – должна позволять указать, какие из полученных посредством выполнения SQL – запроса полей должны отображаться в отчете, в каком порядке они должны отображаться, в каком формате должны отображаться данные. настройка сортировки – должна позволять указать по каким полям и в каком порядке необходимо производить сортировку. настройка OLAP – должна позволять указать поля для группировки и поля для агрегации значений. настройка дополнительных представлений – должна позволять добавлять в отчет любое количество дополнительных представлений, например, трехмерные диаграммы, датчики, гистограммы, круговые диаграммы. модуль отчетов должен позволять осуществлять импорт построенных отчетов в файл формата XLS(X) для последующей обработки в MS Excel. 4.2.3.4.4 Автоматизированная обработка обращений. 94 4.2.3.4.4.1 Общие требования В части автоматизированной обработки поступающих обращений СКДФ, ПОФП СКДФ должна обеспечивать: определение темы обращения клиента (классификация); запуск и ведение определенного сценария обслуживания пользователей (роботизированный сервис); принятие решения о необходимости перевода диалога на оператора; настройка модели определения темы обращения на основе ML-моделей; настройку сценариев обслуживания клиентов в интерфейсе управление ролями пользователей и разграничение прав в интерфейсе. 4.2.3.4.4.2 Требования к классификации обращений и пользователей В части классификации обращений СКДФ, П-ОФП СКДФ должна позволять гибко настраивать классификаторы абонентов и обращений и обеспечивать: управление атрибутами, передаваемыми при запросах пользователей (создание, редактирование, удаление); управление географическими регионами (создание, редактирование, классификаторами абонентов (создание, редактирование, классификаторами обращений (создание, редактирование, удаление); управление удаление); управление удаление). 4.2.3.4.4.3 Требования к пред настроенным актам обслуживания В части классификации обращений СКДФ, П-ОФП СКДФ должна иметь преднастроенные обучающие данные для классификации актов в диалоге с абонентом, обучающие данные для следующих типов актов ведения диалога: Акт приветствия Акт ожидания 95 Акт недовольства Акт прощания Акт завершения диалога Социальный акт. Оператор, обладая соответствующими правами и доступами, должен иметь возможность изменять или добавлять обучающие данные для классификатора того или иного акта - диалоги из исторических данных и с помощью интерактивных методов обучения. 4.2.3.4.4.4 Требования к обучению и управлению автоматизированным обслуживанием В части управления автоматизированным обслуживанием обращений СКДФ, ПОФП СКДФ должна поддерживать гибкий процесс обучения робота. Подсистема должна позволять проводить обучение как на основе предшествующих взаимодействий с клиентами, так и на основе специально созданных данных. Подсистема должна предоставлять возможность управлять ответами и сценариями проведения диалогов автоматизировано, а именно: Управление группами/тематиками обращений (создание, редактирование, удаление); Управление ответами (создание, редактирование, удаление); Управление атрибутами, необходимыми для ответа робота (создание, редактирование, удаление). Для получения атрибутов клиенту будут заданы вопросы в диалоге; Создание сценариев диалогов в специализированном визуальном редакторе. 4.2.3.4.4.5 Требования к подготовке обучающих данных В части управления автоматизированным обслуживанием обращений СКДФ, ПОФП СКДФ должна обеспечить пользовательский интерфейс для обработки архива диалогов (обучающих данных) с целью: 96 Выявления и подтверждения тематик обращения; Формирование справочника синонимов; Формирование библиотеки ответов. П-ОФП СКДФ должна обеспечить: процесс формирования (обучения) ML/DL-моделей с учетом всех внесенных в систему обучающих данных. независимое обучение моделей машинного обучения с целью сократить время от внесения изменений в данных, настройках и алгоритмах до внутреннего тестирования, и публикации изменений. возможность проведения тестовых диалогов от имени технолога. Также должна быть возможность использовать тестовые диалоги как номинальные (заведомо корректные) в процессах машинного обучения и контроля качества работы диалоговой системы. полностью автоматизированное общение с клиентом без участия оператора. поддерживаться расширенные функциональные возможности: Робот идентифицирует ситуации, при которых обращение должно быть передано в обработку соответствующему оператору; Робот автоматически вырабатывает стратегию по уточнению информации у пользователя. 4.2.3.4.4.6 Требования к управлению версиями обучающих данных и обученных моделей СКДФ, П-ОФП СКДФ должна обеспечивать возможность организации процесса тестирования и публикации изменений в моделях путем управления версиями обучающих данных и обученных моделей. Должны быть обеспечена возможность публикации изменений в моделях машинного обучения без остановки обслуживания абонентов. 97 4.2.3.4.4.7 Требования к фиксации действий операторов СКДФ, П-ОФП СКДФ должна обеспечить ведение истории действий сотрудников в специализированном модуле. Модуль предназначен для контроля действий сотрудников и должен предоставлять возможности: просмотра истории действий сотрудников на административном интерфейсе; просмотра активности сотрудников (login/logout). Распознавание и синтез речи. 4.2.3.4.5 4.2.3.4.5.1 Общие требования В части распознавания и синтеза речи П-ОФП СКДФ должна интегрироваться с сервисами автоматизированной обработки голосовых коммуникаций, автоматизированной обработки обращений по стандартному протоколу MRCP v. 1 и WEB API. 4.2.3.4.5.2 Требование к распознаванию речи В части распознавания речи П-ОФП СКДФ должна обеспечивать: распознавание русской речи по грамматикам распознавания SRGS, составленным в соответствии с нотацией Speech Grammar Specification Version 1.0 консорциума W3C; распознавание слитной русской речи по большому словарю (не менее 1 млн. словоформ) общей лексики; распознавание русской речи в режимах онлайн, офлайн (распознавание файлов) и диктовки по WEB API, возможностью выдачи результатов с таймингом и уверенностью; реализацию в виде службы операционной системы с автоматическим перезапуском после сбоев, не пользователя; 98 требующей интерактивного участия пофонемное дикторонезависимое распознавание русской речи, независимо от пола диктора, при этом диктор должен являться носителем русского языка без ярко выраженного акцента или дефектов речи, возраст диктора — от 18 до 60 лет; оптимизацию для распознавания в телефонном канале; автоматическое определение качества поступающего на его вход звукового сигнала и информировать систему IVR о невозможности работы голосового распознавания; формирование списка лучших результатов распознавания (функция N-Best); требования к входному звуковому сигналу, необходимому для работы подсистемы распознавания речи: соотношение сигнал/шум не менее 15 дБ, отсутствие перегрузки, энергия сигнала не менее 15% от максимума, регистрировать подробные протоколы (логи) своей работы, позволяющие быстро и четко диагностировать возникающие проблемы. ведение журнала работы (перевода голоса в текст), позволяющий проводить тюнинг качества распознавания; поддерживать функционал записи всего диалога на уровне MRCP, поддерживать функционал балансировки нагрузки, поддерживать протокол SNMP для системы мониторинга и предоставлять следующие данные: количество занятых и свободных движков, количество сессий, количество ошибок, количество успешных запросов; поддержку протокола SNMP TRAP для оповещения администратора сети о наступлении каких-то критических событий; возможность встраивания классификатора 99 и компонента выделения сущностей; программное обеспечение анализа логов журнала работы для оценки качества распознавания сотрудниками Заказчика; разработку и тонкую настройку грамматик распознавания операторами и администраторами. 4.2.3.4.5.3 Требование к синтезу речи В части синтеза речи П-ОФП СКДФ должна: поддерживать преобразование текста в речь на русском языке для шести голосов и более как мужских, так женских; интегрироваться с сервисами автоматизированной обработки голосовых коммуникаций, автоматизированной обработки обращений по стандартному протоколу MRCP v. 1 или v. 2 и WEB API; интегрироваться по протоколу MRCP и поддерживать кодек G711; обеспечивать синтез русской речи в режимах онлайн и оффлайн по WEB API; соответствовать первому классу качества по норме слоговой разборчивости по ГОСТ Р 50840-95; соответствовать качеству естественности и узнаваемости синтезированной речи должно высшему классу качества по ГОСТ Р 50840-95; быть реализована в виде службы операционной системы с автоматическим перезапуском после сбоев, не требующей интерактивного участия пользователя; обеспечивать плавное изменение темпа воспроизведения речи в диапазоне: замедление темпа до 2 раз, ускорение темпа до 2 раз; обеспечивать изменение высоты основного тона речи на 25 % ниже и 50 % выше относительно среднего значения; обеспечивать учет синтаксического анализа; обеспечивать правильное произношение собственных имен, числительных, 100 сокращений и аббревиатур в процессе обучения Системы; вести подробный журнал (логи) своей работы, позволяющий быстро и четко диагностировать возникающие проблемы; уметь вести журнал работы (перевода текста в звук), позволяющий проводить тюнинг качества синтеза; быть доступна не менее 6 голосов (два мужских и четыре женских); должна поддерживать возможность создания уникального (заказного) голоса; поддерживать функционал балансировки нагрузки; поддерживать протокол SNMP для системы мониторинга и предоставлять следующие данные: количество занятых и свободных речевых движков; количество сессий. поддерживать протокол SNMP TRAP для оповещения администратора сети о наступлении критических событий. иметь программное обеспечение для разработки и тюнинга грамматик синтеза сотрудниками Заказчика. 4.2.4 Требования к техническому обеспечению Для проведения предварительных испытаний Исполнитель обязан обеспечить размещение прикладного программного обеспечения второй очереди СКДФ на собственных вычислительных ресурсах. Техническое обеспечение СКДФ (комплекс технических средств, на котором обеспечивается размещение прикладных компонентов и платформенных подсистем СКДФ) не входит в состав системы и предоставляется Заказчику сторонним поставщиком в виде выделенной инфраструктуры по сервисной модели. Предоставление вычислительных ресурсов Исполнителю в целях обеспечения выполнения работ по настоящему техническому заданию обеспечивается на основании обращения Исполнителя в адрес Заказчика. 101 Исполнитель должен обеспечить перенос разработанных и успешно выдержавших испытания компонентов и подсистемы с собственных вычислительных ресурсов на инфраструктуру, предоставляемую Заказчиком по согласованию с Заказчиком и при участии специалистов с его стороны. 4.2.5 Требования к метрологическому обеспечению Требования не предъявляются. 4.2.6 Требования к организационному обеспечению Организационное обеспечение второй очереди СКДФ должно представлять собой совокупность документов, подготовленных в рамках реализации второй очереди СКДФ, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала второй очереди СКДФ и составных частей, входящих в ее состав, в условиях функционирования, проверки и обеспечения работоспособности. Организационная структура второй очереди СКДФ должна позволять выполнять все предусмотренные Техническим заданием функции с учетом их распределения по уровням управления. Содержание и оформление документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала в условиях функционирования, проверки и обеспечения работоспособности Системы, должны отвечать требованиям ГОСТ 24.209-80. Организационное обеспечение должно быть достаточным для эффективного выполнения персоналом СКДФ возложенных на него обязанностей при осуществлении автоматизированных и связанных с ними неавтоматизированных функций системы. Инструкции организационного обеспечения должны определять действия персонала СКДФ, необходимые для выполнения каждой автоматизированной функции, во всех режимах функционирования второй очереди системы, с учетом заданных требований реализации персоналом СКДФ своих функциональных 102 обязанностей, а также содержать конкретные указания о действиях в случае возникновения аварийных ситуаций или нарушении нормальных условий функционирования. В процессе выполнения работ по настоящему Техническому заданию Заказчиком должны быть определены должностные лица, ответственные за: администрирование составных частей второй очереди СКДФ; обеспечение безопасности информации, обрабатываемой во второй очереди СКДФ; управление работой персонала по обслуживанию второй очереди СКДФ. К работе со второй очередью СКДФ должны допускаться сотрудники, имеющие навыки работы на персональном компьютере, ознакомленные с правилами эксплуатации и прошедшие обучение работе с компонентами второй очереди системы в объеме, предусмотренном настоящим ТЗ. Основные процессы деятельности пользователей системы в части компонентов и составных частей, создаваемых в составе второй очереди СКДФ, должны быть регламентированы следующими нормативными документами, которые должны быть разработаны в рамках выполнения работ по настоящему Техническому заданию: регламент действий технического персонала при возникновении нештатного режима функционирования компонентов из состава второй очереди системы; регламент работы службы технической поддержки второй очереди СКДФ; регламенты резервного копирования и восстановления данных компонентов второй очереди системы; регламент регулярного технического обслуживания компонентов второй очереди системы. Порядок и функции, связанные с обеспечением эксплуатации и администрированием компонентов второй очереди СКДФ, платформенных подсистем второй очереди СКДФ, поддержанием информационного и других видов обеспечения, должен быть отражен в рабочей документации на соответствующие составные части второй очереди системы. 103 4.2.7 Требования к методическому обеспечению В качестве методического обеспечения должны быть использованы как минимум следующие нормативные правовые акты РФ и нормативно-технические документы: Указ Президента Российской Федерации от 07.05.2018 №204 «О национальных целях и стратегических задачах развития Российской Федерации на период до 2024 года»; Паспорт национального проекта «Безопасные и качественные автомобильные дороги»; Паспорта федеральных проектов «Дорожная сеть», «Общесистемные меры развития дорожного хозяйства»; Технический регламент таможенного союза «Безопасность автомобильных дорог» (ТР ТС 014/2011); Федеральный закон от 8 ноября 2007 года № 257-ФЗ «Об автомобильных дорогах и о дорожной деятельности в Российской Федерации и о внесении изменений в отдельные законодательные акты Российской Федерации»; Федеральный закон от 17.07.2009 №145-ФЗ «О государственной компании «Российские автомобильные дороги» и о внесении изменений в отдельные законодательные акты Российской»; Программа деятельности государственной компании «Российские автомобильные дороги» на долгосрочный период (2010-2021 годы); Постановление Правительства РФ от 17.11.2010 №928 (ред. от 21.02.8018) «О перечне автомобильных дорог общего пользования федерального значения»; СНиП 2.05.02-85. Автомобильные дороги (утв. Постановлением Госстроя СССР от 07.12.1985 № 233) (ред. от 30.06.2003); СНиП 2.07.01-89. Градостроительство. Планировка и застройка городских и сельских поселений" (утв. Постановлением Госстроя СССР от 16.05.1989 № 78) (ред. от 25.08.1993); «Бюджетный кодекс Российской Федерации» от 31.07.1998 №145-ФЗ, статья 179.4; 104 Федеральный закон «О федеральном бюджете на 2019 год и на плановый период 2020 и 2021 годов» от 29.11.2018 №459-ФЗ, приложение 13; законы о бюджетах субъектов Российской Федерации; программы дорожной деятельности субъектов Российской Федерации; Приказ Федеральной службы государственной статистики от 15.06.2012 №346 «Об утверждении статистического инструментария для организации Министерством транспорта Российской Федерации федерального статистического наблюдения за использованием средств дорожных фондов»; Приказ Федеральной службы государственной статистики от 23 сентября 2013 г. № 379 «Об утверждении статистического инструментария для организации Федеральным статистического пользования наблюдения федерального, дорожным за агентством автомобильными регионального или федерального дорогами общего межмуниципального значения»; Приказ Федеральной службы государственной статистики от 31.08.2017 №564 «Об утверждении статистического инструментария для организации федерального статистического наблюдения за рыночными услугами, туризмом, транспортом и административными правонарушениями в сфере экономики» (в части утверждения формы федерального статистического наблюдения № 3-ДГ (мо) «Сведения об автомобильных дорогах общего пользования местного значения и искусственных сооружениях на них, находящихся в собственности муниципальных образований» (приложение № 9); Письмо Министерства транспорта Российской Федерации от 27.01.2012 №ОБ-23/590; Методические рекомендации по проведению работ по сбору, анализу, мониторингу, актуализации и определению стоимости строительства, реконструкции, капитального ремонта, ремонта и содержания 1 км автомобильных дорог общего пользования федерального, регионального 105 (межмуниципального) и местного значения; Постановление Правительства Российской Федерации от 31 октября 2018 г. № 1288 «Об организации проектной деятельности в Правительстве Российской Федерации»; Методические рекомендации по организации проектной деятельности в федеральных органах исполнительной власти, утв. Аппаратом Правительства РФ 12.03.2018 № 1937п-П6; Методические указания по мониторингу и внесению изменений в национальные проекты (программы) и федеральные проекты, утверждены президиумом Совета при Президенте Российской Федерации по стратегическому развитию и национальным проектам (протокол от 3 декабря 2018 года №14); Регламент взаимодействия Министерства транспорта Российской Федерации, Федерального дорожного агентства, Государственной компании «Российские автомобильные дороги», исследовательский Федерации, и национального дороги», ФАУ институт, администраций муниципальных проекта утвержденный «Российский образований «Безопасные первым и дорожный научно- субъектов Российской в реализации рамках качественные заместителем автомобильные Министра транспорта Российской Федерации 14.03.2019; Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; Постановление Правительства Российской Федерации от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских 106 программ для электронных вычислительных машин и баз данных». 107 5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ Создание СКДФ осуществляется в рамках работ по отдельным частным техническим заданиям и договорам в целях оптимизации сроков создания и ввода в эксплуатацию отдельных элементов системы, повышения эффективности управления созданием системы и предусматривает: создание первой очереди СКДФ, включая формирование необходимого информационного обеспечения; создание П-ОИБ СКДФ (Частное техническое задание представляется в виде справочного Приложения к настоящему ТЗ); предоставление необходимой для функционирования СКДФ аппаратнопрограммной инфраструктуры по сервисной модели ; приобретение заказчиком прав на использование предусмотренного проектными решениями программного обеспечения; выполнение работ по созданию второй очереди СКДФ и СКДФ в целом в соответствии с требованиями, предъявляемыми настоящим техническим заданием. Организацию взаимодействия и координацию исполнителей работ обеспечивает Заказчик. Работы по настоящему Техническому заданию выполняются в 4 (четыре) этапа. Документирование, оформление и предъявление результатов работ каждого из этапов должно осуществляться в порядке, предусмотренном Договором на выполнение работ и в соответствии с требованиями, предъявляемыми настоящим Техническим заданием. 108 Таблица 1. Состав, содержание и сроки выполнения этапов работ по созданию СКДФ по настоящему техническому заданию № п/п Наименование выполняемых работ 1 1.1. ЭТАП 1 Разработка частных технических заданий на мобильные интерфейсы (приложения) второй очереди СКДФ 1.2 Создание РМ «Подрядчик» в соответствии с требованиями ТЗ в части п. 4.2.3.3.3 (пп. 1, 2, 4) Форма представления результата Срок выполнения работ, дней 25.12.2019 Согласованные Заказчиком частные технические задания на мобильные интерфейсы (приложения) второй очереди СКДФ Протокол предварительных испытаний компонента «Портал подрядной организации» Рабочая документация на компонент «Портал подрядной организации» 1.3 Создание П-ОФП СКДФ второй очереди в соответствии с требованиями ТЗ в части п. 4.2.3.4.3, 4.2.3.4.5. Протокол предварительных испытаний П-ОФП СКДФ второй очереди в объеме реализованных функций Рабочая документация на П-ОФП СКДФ второй очереди 2 2.1 15.05.2020 ЭТАП 2 Создание П-ОФП СКДФ Рабочая документация Пвторой очереди в полном ОФП СКДФ второй объеме очереди. Дистрибутивы программного обеспечения П-ОФП. 109 Акт установки и настройки ПО П-ОФП. Протокол предварительных испытаний П-ОФП СКДФ второй очереди. Акт о завершении опытной эксплуатации ПОФП СКДФ второй очереди. 2.2 3 3.1 Создание прикладного компонента «Портал подрядной организации» в соответствии с требованиями ТЗ в части п. 4.2.3.2.1, 4.2.3.2.2, 4.2.3.2.6 ЭТАП 3 Создание прикладного компонента «Портал подрядной организации» в соответствии с требованиями ТЗ в части п. 4.2.3.2.3, 4.2.3.2.4, 4.2.3.2.5 Протокол приемочных испытаний П-ОФП СКДФ второй очереди Протокол предварительных испытаний компонента «Портал подрядной организации» СКДФ Рабочая документация на компонент «Портал подрядной организации» 01.10.2020 Протокол предварительных испытаний компонента «Портал подрядной организации» Протокол опытной эксплуатации компонента «Портал подрядной организации» Протокол приемочных испытаний компонента 110 «Портал подрядной организации». Рабочая документация на компонент «Портал подрядной организации» СКДФ 3.3 Создание РМ «Подрядчик» в соответствии с требованиями ТЗ в п. 4.2.3.3.3 (пп. 3, 5, 6) Протокол предварительных испытаний РМ «Подрядчик» Акт о завершении опытной эксплуатации РМ «Подрядчик» в соответствии с согласованной программой опытной эксплуатации; Протокол приемочных испытаний РМ «Подрядчик»; Рабочая документация на РМ «Подрядчик» 3.4 Создание МП «Пользователь дорог» в соответствии с требованиями ТЗ в п. 4.2.3.3.2 Протокол предварительных испытаний МП «Пользователь дорог»; Акт о завершении опытной эксплуатации МП «Пользователь дорог» Протокол приемочных испытаний МП «Пользователь дорог» 111 Рабочая документация на МП «Пользователь дорог» 3.5 Создание «Руководитель» соответствии требованиями ТЗ 4.2.3.3.1 РМ в с в п. Протокол предварительных испытаний РМ «Руководитель» Акт о завершении опытной эксплуатации РМ «Руководитель». Протокол приемочных испытаний РМ «Руководитель» Рабочая документация на РМ «Руководитель» 3.6 Проведение опытной эксплуатации и приемочных испытаний ПОФП СКДФ второй очереди. Акт о завершении опытной эксплуатации ПОФП СКДФ второй очереди. Протокол приемочных испытаний П-ОФП СКДФ второй очереди. Рабочая документация на П-ОФП СКДФ второй очереди 4 ЭТАП 4 4.1 Подготовка и проведение Протокол проведения комплексных приемочных комплексных приемочных испытаний СКДФ испытаний СКДФ 01.11.2020 Рабочая документация на составные части СКДФ из состава второй очереди 112 6 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ И ЕЕ СОСТАВНЫХ ЧАСТЕЙ 6.1 Виды, состав, объем и методы испытаний В рамках выполнения работ по настоящему Техническому заданию на различных этапах предусмотрено проведение следующих видов испытаний: предварительные испытания; опытная эксплуатация; приемочные испытания; комплексные приемочные испытания. Объем и методы испытаний приводятся в разрабатываемых исполнителем программах и методиках соответствующего вида испытаний. В качестве приложения в программы и методики испытаний могут включаться тесты (контрольные примеры). По согласованию между Заказчиком и Исполнителем испытания и приемку программных средств второй очереди СКДФ допускается проводить на технических средствах Исполнителя при создании условий получения достоверных результатов испытаний. 6.2 Требования к проведению предварительных испытаний Предварительные испытания должны проводиться для проверки соответствия программных средств второй очереди СКДФ требованиям настоящего Технического задания в объеме функций, предусмотренных к реализации в рамках отдельных этапов выполнения работ. До начала предварительных испытаний должна быть предусмотрена разработка и согласование с Заказчиком «Программы и методики предварительных испытаний». Предварительные испытания проводятся Исполнителем с участием представителей Заказчика. Результаты предварительных испытаний оформляются протоколом проведения предварительных испытаний. 113 6.3 Требования к проведению опытной эксплуатации Опытная эксплуатация проводится в соответствии с программой, согласованной Заказчиком. Результаты опытной эксплуатации должны быть оформлены Актом о завершении опытной эксплуатации, который утверждается Заказчиком. В ходе опытной эксплуатации должны быть устранены выявленные недостатки, проведены повторные контрольные проверки, представлены документы, подтверждающие их устранение. 6.4 Требования к проведению приемочных испытаний Приемочные испытания проводятся при положительном заключении по результатам опытной эксплуатации составных частей СКДФ. Приемочные испытания проводятся на территории Заказчика и на его технических средствах в сроки, определенные в соответствии с этапами реализации, предусмотренными настоящим Техническим заданием, и в объеме и порядке, предусмотренными «Программой и методикой приемочных испытаний». «Программа и методика приемочных испытаний» разрабатывается Исполнителем и утверждается Заказчиком. Статус приемочной комиссии определятся Заказчиком до начала проведения испытаний. В состав комиссии входят представители Заказчика и Исполнителя. Соисполнители могут привлекаться по согласованию с Заказчиком. Результаты проведения приемочных испытаний оформляются протоколом с заключением о соответствии требованиям ТЗ и готовности к комплексным приемочным испытаниям. 6.5 Требования к проведению комплексных приемочных испытаний Комплексные приемочные испытания проводятся на территории Заказчика и на его технических средствах в сроки, определенные в соответствии с этапами реализации, предусмотренными настоящим Техническим заданием, и в объеме и порядке, предусмотренными «Программой и методикой комплексных приемочных испытаний», которая разрабатывается Исполнителем и утверждается Заказчиком. 114 Комплексные приемочные испытания проводятся с целью проверки соответствия СКДФ в целом всем требованиям, предъявляемым к системе и корректности функционирования и взаимодействия всех элементов в составе Системы. Участие в комплексных приемочных испытаниях Исполнителей работ, предусмотренных в рамках других договоров, обеспечивается Заказчиком. Результаты проведения комплексных приемочных испытаний оформляются протоколом с заключением о соответствии СКДФ требованиям ТЗ и готовности к вводу в эксплуатацию. 6.6 Требования к передаче дистрибутивов По успешном Исполнитель окончании должен предварительных предоставить Заказчику и приемочных рабочую испытаний документацию на программные средства второй очереди СКДФ, а также дистрибутивы программных средств второй очереди СКДФ, в составе: архив с исходными кодами программных модулей; дамп проектной базы данных с актуальной информацией. Дистрибутивы предоставляются на компакт-диске в виде файлового архива. Передаваемые дистрибутивы должны быть достаточными для повторного развертывания программных средств второй очереди СКДФ. Компакт диск должен иметь маркировку с обозначением товарного знака/наименования организации разработчика, наименования, номера версии, порядкового номера и даты изготовления. Маркировка должна быть нанесена на программное изделие полиграфическим способом. Маркировка должна быть четкой и сохраняться в течение срока хранения компакт-диска. Компакт диск должен быть упакован в твердую упаковку. Упаковка должна иметь маркировку в виде наклейки, выполненной полиграфическим способом, с обозначением товарного знака/наименования организации разработчика, наименования, номера версии, порядкового номера и даты изготовления. Информация, содержащаяся на маркировке компакт-диска и на маркировке упаковки должна совпадать. 115 6.7 Общие требования к приемке работ по этапам Приемка работ осуществляется Заказчиком на основании уведомления Исполнителя о готовности к приемке соответствующего этапа. Приемка работ осуществляется Заказчиком в соответствии с требованиями Договора на выполнение работ на основании уведомления Исполнителя о готовности к приемке соответствующего этапа. По результатам приемки подписывается акт сдачи-приемки выполненных работ. Все создаваемые в рамках настоящей работы программные компоненты и подсистемы (за исключением покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (например, на компакт-диске) в соответствии с требованиями, указанными в Разделе 6 ТЗ. 116 ПРИЛОЖЕНИЕ 1 ПЕРЕЧЕНЬ СОКРАЩЕНИЙ И УСЛОВНЫХ НАИМЕНОВАНИЙ Термин, сокращение .NET Core Определение Модульная платформа для разработки программного обеспечения с открытым исходным кодом Apache Kafka API ASP.NET Core Диспетчер сообщений на Java платформе Программный интерфейс приложения Кроссплатформенная, высокопроизводительная среда с открытым исходным кодом для создания современных облачных приложений, подключенных к Интернету C# Объектно-ориентированный язык программирования CD/DVD DNS Типы оптического носителя информации Domain Name System - компьютерная распределенная система для получения информации о доменах etcd Распределённая система хранения параметров конфигурации, задаваемых как пара «Ключ»«Значение» ETL Один из основных процессов в управлении хранилищами данных, включающий в себя следующие методы работы с данными: Extract (извлечения), Transform (преобразования) и Load (загрузки) данных GeoServer Программное обеспечение с открытым исходным кодом, написанное на Java, предоставляющее возможность администрирования и публикации геоданных на сервере GeоJSON Открытый формат, предназначенный для хранения географических структур данных, основанный на JSON (Geo JavaScript Object Notation) GUI HTTP Графический интерфейс пользователя Протокол передачи гипертекста 117 Термин, сокращение IP-адрес Определение Internet Protocol - адрес. Уникальный сетевой адрес узла в компьютерной сети, построенной на основе стека протоколов TCP/IP ISO ISO/IEC 9075 “Database Language SQL” Международная организация по стандартизации Седьмая редакция стандартов ISO (1987) и ANSI (1986) для языка запросов SQL к базе данных Java Cтрого типизированный объектно-ориентированный язык программирования JavaScript JSON Web Tokens Мультипарадигменный язык программирования Текстовый формат обмена данными (JavaScriptObjectNotation), основанный на JavaScript JSON Web Tokens Открытый стандарт для создания токенов доступа, основанный на формате JSON LDAP сервер Lightweight Directory Access Protocol - протокол прикладного уровня для доступа к службе каталогов Leaflet Библиотека визуализации пространственных данных OAuth Открытый протокол (схема) авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль OGC OpenIDConnect Open Geospatial Consortium Спецификация, которая организует процесс обмена данными между поставщиками учетных данных и проверяющими сторонами без необходимости вводить многочисленные данные OpenLDAP Облегчённый протокол доступа к службам каталогов OS Linux PATCH Операционная система на базе ядра Linux Информация, предназначенная для автоматизированного внесения определённых изменений в систему 118 Термин, сокращение PL/pgSQL Определение Процедурное расширение языка SQL, используемое в СУБД PostgreSQL Positive Technologies Application Firewall Инновационная система защиты, которая обеспечивает непрерывную защиту приложений, пользователей и инфраструктуры и помогает соответствовать стандартам безопасности. POST Проверка аппаратного обеспечения компьютера (Power-On Self-Test), выполняемая при его включении PostGIS Открытое программное обеспечение, добавляющее поддержку географических объектов в реляционную базу данных PostgreSQL PostgreSQL Свободная объекто-реляционная система управления базами данных Protocol Buffers Протокол сериализации (передачи) структурированных данных, предложенный публичной компанией Google как эффективная бинарная альтернатива текстовому формату XML RAID Отказоустойчивый массив дисков (redundant array of independent disks), использующийся в технология виртуализации данных, которая объединяет несколько дисков в логический элемент для избыточности и повышения производительности RESTAPI Representational State Transfe - архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST-интерфейс RFC Интерфейс вызова удаленных процедур Документ, охватывающий технические спецификации и Стандарты, широко используемые во Всемирной сети SAS (data) Данные формата SAS, использующиеся в системах статистического анализа и разработанный компанией SAS 119 Термин, сокращение SNMP Определение Simple Network Management Protocol - стандартный интернет-протокол для управления устройствами в IP-сетях sql-запрос Запрос к базе данных с помощью языка программирования SQL SSD State and Registry URL UUID VRRP Диски постоянной памяти на основе флэш-памяти Шаблоны проектирования «реестр» и «состояние» Унифицированный указатель ресурса Универсальный уникальный идентификатор Virtual Router Redundancy Protocol - сетевой протокол, предназначенный для увеличения доступности маршрутизаторов, выполняющих роль шлюза по умолчанию. Web-приложение Клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера WFS Стандарт интерфейса обслуживания веб-объектов Open Geospatial Consortium предоставляет интерфейс, позволяющий запрашивать географические объекты в Интернете с помощью вызовов, не зависящих от платформы. WMS XML Web Map Service Расширяемый язык разметки (eXtensible Markup Language) А/д АвОп АРМ БД БИК ГЗ ГИБДД Автомобильная дорога Аварийно-опасный участок Автоматизированное рабочее место База данных Банковский идентификационный код Единая информационная система в сфере закупок Государственная инспекция безопасности дорожного движения ГК «Автодор» Государственная компания «Российские автомобильные дороги» 120 Термин, сокращение Госстрой СССР Определение Государственный исполнительный орган Союза Советских Социалистических Республик ГОСТ ДР ДТП ЕИС ЕСИА ЕСПД ЖЦ Ид.загрузки ИНН КБК КВР КЖЦ КОСГУ Межгосударственный стандарт Дорожные работы Дорожно-транспортное происшествие Единая информационная система в сфере закупок Единая система идентификации и авторизации Единая система программной документации Жизненный цикл Идентификационный номер загрузки Идентификационный номер налогоплательщика Код бюджетной классификации Коды видов расходов Контракты жизненного цикла Классификация операций сектора государственного управления КПП КТ Минтранс НМЦД НМЦК НП БКАД Код причины постановки на учет Контрольная точка Министерство транспорта Российской Федерации Начальная максимальная цена договора Начальная максимальная цена контракта Национальный проект "Безопасные и качественные автомобильные дороги" НПА НСИ Объекты ДХ ОГРН Нормативно-правовые акты Нормативно-справочная информация Объекты дорожного хозяйства Основной государственный регистрационный номер ОДД ОЗУ ОКАТО Организация дорожного движения Оперативное запоминающее устройство Общероссийский классификатор объектов административно-территориального деления Общероссийский классификатор органов государственной власти и управления ОКОГУ 121 Термин, сокращение ОКОПФ ОКПД2 ОКПО Определение Общероссийский классификатор организационноправовых форм Общероссийский классификатор продукции по видам экономической деятельности Общероссийский классификатор предприятий и организаций ОКТМО Общероссийский классификатор территорий муниципальных образований ОНФ Общественное движение "Общероссийский народный фронт" ОС ПВГК П-ВИД Операционная Система Пункт весогабаритного контроля Подсистема информационного взаимодействия с внешними источниками данных П-ГИС ПДД П-НСИ Геоинформационная подсистема Правила дорожного движения Подсистема ведения нормативно-справочной информации и метаданных ПО П-ОИБ Программное обеспечение Подсистема обеспечения информационной безопасности П-ОТС Подсистема открытых технологических сервисов предоставления и получения информации П-ОФП Подсистема обеспечения функционирования, поддержки пользователей и эксплуатации программно-технических средств П-ОХД Подсистема централизованной обработки и хранения данных ПП П-УНСИ Представление периодичности Подсистема управления единой нормативносправочной информацией РМ «Специалист» РФ Мобильное рабочее место специалиста Российская Федерация 122 Термин, сокращение СКДФ Определение Общедоступная информационная система контроля за формированием и использованием средств дорожных фондов СМБ СНиП СУБД СУПД Субъекты малого и среднего бизнеса Строительные нормы и правила Система управления базами данных Компонент "Система управления проектной деятельностью" ТЗ ТС ТСОДД Техническое задание Транспортное средство Техническое средство организации дорожного движения УДС УПР ФАУ "РОСДОРНИИ" Улично-дорожная сеть Участок проведения работ Федеральное автономное учреждение «Российский дорожный научно-исследовательский институт" ФЗ ФИАС ФКУ ЦОД ЦПУ ЧТЗ ЭТП Федеральный закон Федеральная информационная адресная система Федеральное казённое учреждение Центр обработки данных Центральное процессорное устройство Частное техническое задание Электронные торговые площадки 123 ПРИЛОЖЕНИЕ 2 ПЕРЕЧЕНЬ ОПРЕДЕЛЕНИЙ Термин Определение Автомобильная дорога Объект транспортной инфраструктуры, предназначенный для движения транспортных средств и включающий в себя земельные участки в границах полосы отвода автомобильной дороги и расположенные на них или под ними конструктивные элементы (дорожное полотно, дорожное покрытие и подобные элементы) и дорожные сооружения, являющиеся ее технологической частью, защитные дорожные сооружения, искусственные дорожные сооружения, производственные объекты, элементы обустройства автомобильных дорог Перечень участков автомобильных дорог, сгруппированных с целью упрощения процесса планирования работ по содержанию автомобильных дорог. Участки группируются в дистанцию таким образом, чтобы запланированная работа определенного вида выполнялась на каждом участке дистанции Документально зафиксированное относительное гражданское правоотношение (договор, контракт) или иной документ (государственное задание), устанавливающий требования к составу, качеству и (или) объему (содержанию), условиям, порядку и результатам оказания организацией услуг (выполнения работ) по содержанию и ремонту автомобильных дорог Организация или физическое лицо, обязующийся выполнить определенный вид работ на основании действующего обязательства. Работы осуществляются материалами и силами подрядчика. Он вправе привлечь еще одну подрядную организацию (Субподрядчика) для выполнения отдельного вида работ, которые подрядчик, к примеру, не успевает осуществить лично Документ, регламентирующий состав и порядок выполняемых работ, а также их количественные характеристики за единицу измерения. Используется при планировании и контроле исполнения обязательства Комплекс работ по поддержанию надлежащего технического состояния автомобильной дороги, оценке ее технического состояния, а также по организации и обеспечению безопасности дорожного движения. Включает в себя работы по ямочному ремонту, в т.ч. ремонт картами Метод восстановления мелких неглубоких повреждений, которые подлежат устранению в довольно короткие сроки, установленные «Требованиями к эксплуатационному состоянию‚ допустимому по условиям обеспечения Дистанция Обязательство Подрядчик Регламент выполнения работ Содержание Ямочный ремонт 124 Термин Линейное задание Точечное задание Определение безопасности дорожного движения (ГОСТ Р 50597-93)» - от 5 до 10 суток в зависимости от категории дороги. Ямочный ремонт включает в себя: ликвидацию ям‚ выбоин‚ сколов‚ заделку трещин Задание на выполнение работ по содержанию участков автомобильных дорог, которое осуществляется с помощью мобильного приложения с записью трека движения транспортного средства, подтверждающего факт выполнения работ Задание на выполнение работ по содержанию участка автомобильной дороги, которое выполняется в мобильном приложении с обязательным приложением фотоматериалов, подтверждающих факт выполнения работ 125
