На основании подпункта "б" пункта 7 механизмов реализации проектов в рамках цифровой повестки Евразийского экономического союза, утвержденных Решением Евразийского межправительственного совета от 1 февраля 2019 г. № 1, и абзаца третьего пункта 6 Решения Совета Евразийской экономической комиссии от 14 июля 2021 г. № 63 "О реализации проекта "Цифровое техническое регулирование в рамках Евразийского экономического союза" Коллегия Евразийской экономической комиссии решила:

      1. Утвердить прилагаемое техническое задание на оказание услуг по реализации проекта "Цифровое техническое регулирование в рамках Евразийского экономического союза".

      2. Настоящее Решение вступает в силу по истечении 10 календарных дней с даты его официального опубликования.

Оказание услуг по реализации проекта "Цифровое техническое регулирование в рамках Евразийского экономического союза"

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Москва, 2022

Оглавление

      1 Общие сведения

      1.1 Наименование проекта

      1.1.1 Полное наименование проекта

      1.1.2 Сокращенное наименование проекта

      1.2 Основания для реализации проекта

      1.3 Заказчик

      1.4 Исполнитель

      1.5 Плановые сроки начала и окончания оказания услуг

      1.6 Сведения о порядке финансирования

      1.6.1 Источник финансирования

      1.6.2 Порядок финансирования

      1.7 Порядок оформления и предъявления Заказчику результатов оказания услуг

      1.8 Перечень сокращений

      1.9 Термины и определения

      1.10 Порядок внесения изменений и дополнений

      2 Назначение и цели реализации проекта

      2.1 Назначение проекта

      2.2 Цели реализации проекта

      3 Характеристика объекта автоматизации

      3.1 Краткие сведения об объекте цифровизации

      3.2 Принципы создания и развития проекта

      4 Требования к проекту

      4.1 Требования к проекту в целом

      4.1.1 Требования к структуре Системы

      4.1.2 Требования к архитектуре системы

      4.1.3 Требования к локализации системы

      4.1.4 Требования к численности и квалификации персонала системы и режиму его работы

      4.1.5 Требования к нагрузке на систему

      4.1.6 Требования к доступности и надежности

      4.1.7 Требования к информационной безопасности

      4.1.8 Требования к эргономике и технической эстетике

      4.1.9 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

      4.1.10 Требования к сохранности информации при авариях

      4.1.11 Требования по стандартизации и унификации

      4.2 Требования к функциям

      4.2.1 Требования к разработке методологии цифровой трансформации

      4.2.2 Требования к разработке методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам

      4.2.3 Требования к наднациональному компоненту

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

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

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

      4.2.7 Требование к разработке программного обеспечения интерфейсов программных приложений для подключения внешних сервисов

      4.2.8 Требования к разработке предложений по развитию проекта

      4.3 Требования к видам обеспечения системы

      4.3.1 Требования к информационному обеспечению системы

      4.3.2 Требования к программному обеспечению системы

      4.3.3 Требования к техническому обеспечению системы

      5 Состав и содержание оказания услуг

      5.1 Календарный план оказания услуг

      5.2 Требования к оказанию услуг по каждой стадии

      5.2.1 Стадия "Разработка методологии цифровой трансформации"

      5.2.2 Стадия "Разработка методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам"

      5.2.3 Стадия "Разработка требований к функциональному наполнению компоненты Системы"

      5.2.4 Стадия "Разработка технического проекта компоненты Системы"

      5.2.5 Стадия "Разработка программного обеспечения компоненты Системы"

      5.2.6 Стадия "Комплексное тестирование Системы"

      5.2.7 Стадия "Доработка программного обеспечения"

      5.2.8 Стадия "Развертывание и конфигурирование"

      5.2.9 Стадия "Опытная эксплуатация"

      5.2.10 Стадия "Ввод в промышленную эксплуатацию"

      5.2.11 Стадия "Разработка предложений по развитию"

      5.2.12 Стадия "Сбор и подготовка контента"

      5.2.13 Стадия "Наполнение контентом"

      6 Порядок контроля и приемки

      6.1 Общие положения

      6.2 Требования к видам, составу, объему и методам испытаний системы

      6.3 Требования к проведению тестирования Системы (предварительных испытаний)

      6.4 Требования к проведению опытной эксплуатации

      6.5 Требования к проведению приемочных испытаний

      6.6 Требования к гарантии качества выполняемых работ

      6.6.1 Требования к объему гарантий качества оказываемых услуг

      7 Требования к составу и содержанию услуг по подготовке объекта автоматизации к вводу системы в действие

      7.1 Развертывание и конфигурирование

      7.2 Требования к инструктажу персонала

      8 Требования к документированию

      8.1 Требования к документам по методологии цифровой трансформации

      8.2 Требования к методической документации, положениям и соглашениям по проекту

      8.3 Требования к частному техническому заданию

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

      8.5 Требования к рабочей документации

1. Общие сведения

      1.1 Наименование проекта

      1.1.1 Полное наименование проекта

      Цифровое техническое регулирование в рамках Евразийского экономического союза.

      1.1.2 Сокращенное наименование проекта

      ЦТР.

      1.2 Основания для реализации проекта

      Основанием для реализации проекта являются, верхнеуровневый план мероприятий ("дорожная карта") по реализации проекта "Цифровое техническое регулирование в рамках Евразийского экономического союза" (далее – план мероприятий) и паспорт проекта "Цифровое техническое регулирование в рамках Евразийского экономического союза" (далее - Паспорт), утвержденные Решением Совета Евразийской экономической комиссии от 14 июля 2021 г. № 63 "О реализации проекта "Цифровое техническое регулирование в рамках Евразийского экономического союза" (далее – Решение).

      1.3.Заказчик

      Евразийская экономическая комиссия (далее Комиссия).

      1.4.Исполнитель

      Определяется по результатам двухэтапного конкурса в соответствии с решением Совета Евразийской экономической комиссии от 25 января 2012 г. № 5 "О Положении о размещении заказов и заключении договоров на поставку товаров, выполнение работ и оказание услуг для нужд Евразийской экономической комиссии".

      1.5. Плановые сроки начала и окончания оказания услуг

      Дата начала оказания услуг – с даты подписания договора на оказание услуг (далее – Договор).

      Дата окончания оказания услуг – в соответствии с условиями договора.

      Состав и очередность оказания услуг определяются в соответствии с разделом 5.

      1.6 Сведения о порядке финансирования

      1.6.1 Источник финансирования

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

      1.6.2 Порядок финансирования

      Финансирование услуг осуществляется в порядке, определенном Договором, в соответствии с Календарным планом оказания услуг (раздел 5).

      1.7 Порядок оформления и предъявления Заказчику результатов оказания услуг

      Результаты оказания услуг передаются Заказчику в порядке, определенном Договором, в соответствии с Календарным планом оказания услуг (раздел 5).

      1.8 Перечень сокращений

      Для целей настоящего Технического задания используется следующий перечень сокращений:

      1.9 Термины и определения

      В настоящем техническом задании используются следующие термины и определения:

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

      Интеграционный сервис – программное обеспечение реализующее интеграционное взаимодействие между компонентами/подсистемами Системы или Системой и внешними ИС;

      Координационная группа — рабочая группа, осуществляющая координацию реализации проекта, в состав которой входят представители Офиса управления инициативами, департаментов Комиссии, уполномоченных органов и (или) организаций государств – членов;

      Консорциум — объединение организаций государств-членов без образования юридического лица, осуществляющее деятельность в целях реализации проекта на основании соглашения о консорциуме. Определение консорциума и особенности его создания установлены Решение Евразийского Межправительственного Совета от 1 февраля 2019 г. №1 "О механизмах реализации проектов в рамках цифровой повестки ЕАЭС";

      Координатор консорциума — юридическое лицо, координирующее деятельность членов консорциума при разработке и реализации проекта;

      Наднациональный компонент (ННК) — универсальное платформенное решение по созданию и подключению пользовательских интерфейсов;

      Операторы национальных сервисов - национальные органы и/или уполномоченные ими организации в области технического регулирования, стандартизации и метрологии;

      Операторы сервисов государств-членов (далее – операторы сторонних сервисов) — организации, юридические лица, в том числе индивидуальные предприниматели, которые оказывают услуги в соответствии с выданными им лицензиями;

      Проект ЦТР — комплекс взаимосвязанных мероприятий, предназначенных для создания уникальных результатов в условиях временных и ресурсных ограничений. В настоящих документах - создание системы "Цифровое техническое регулирование Союза" (далее - проект);

      Сборочный конвейер – CI/CD конвейер;

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

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

      Компонент – элемент Системы, определенный в пунктах 17-26 верхнеуровневого плана мероприятий ("дорожная карта") по реализации проекта;

      Подсистема – элемент компонента Системы, обладающий обособленным набором функциональных требований;

      Модуль – архитектурный элемент Системы, реализующий отдельные функциональные требования подсистемы или компонента Системы;

      Единый перечень продукции – единый перечень продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

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

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

      Машиночитаемый формат – документ, представленный в форматах (цифровых форматах), пригодных для автоматического и/или автоматизированного использования;

      Третья страна — государство, не являющееся государством — членом Союза.

      1.10 Порядок внесения изменений и дополнений

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

2 Назначение и цели реализации проекта

      2.1 Назначение проекта

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

      - единого перечня продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

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

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

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

      2.2 Цели реализации проекта

      Основными целями проекта является создание:

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

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

      - сервиса разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов;

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

      - программного обеспечения интерфейсов программных приложений для подключения внешних сервисов

3 Характеристика объекта автоматизации

      3.1 Краткие сведения об объекте цифровизации

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

      Цифровое техническое регулирование должно включать в себя:

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

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

      - сервис разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов;

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

      - программное обеспечение интерфейсов программных приложений для подключения внешних сервисов

      В рамках проекта также должен быть оказан комплекс услуг:

      - по разработке методологии цифровой трансформации в части:

      ○ обязательных требований к продукции;

      ○ выбора классификатора (классификаторов) продукции;

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

      ○ разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов Союза;

      ○ приведения текстов технических регламентов в машиночитаемый формат (при необходимости);

      - по разработке методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам;

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

      3.2 Принципы создания и развития проекта

      Система должна создаваться в соответствии с правом ЕАЭС и не противоречить законодательству государств – членов Союза.

      Система должна быть масштабируемой и иметь средства адаптации к изменениям бизнес-процессов.

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

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

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

      Разработка Системы должна осуществляться в системе управления версиями разработки. При этом, должна быть реализована модель ветвления в соответствии с разделом 4.1.2.5.

      Требования к организации сборочного конвейера приведены в разделе 4.1.2.5.

4 Требования к проекту

      4.1 Требования к проекту в целом

      4.1.1 Требования к структуре Системы

      Система должна состоять из следующих компонентов:

      - наднациональный компонент. Детальные требования приведены в разделе 4.2.3;

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

      - сервис разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов. Детальные требования приведены в разделе 4.2.5;

      - сервис формирования полного набора данных об обязательных требованиях к продукции, формах оценки соответствия. Детальные требования приведены в разделе 4.2.6;

      - программное обеспечение интерфейсов программных приложений для подключения внешних сервисов. Детальные требования приведены в разделе 4.2.7.

      Также, в рамках реализации проекта должны быть осуществлены:

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

      - разработка методической документации, положений и соглашений по проекту, в том числе по наднациональному компоненту и разрабатываемым сервисам. Детальные требования приведены в разделе 4.2.2;

      - разработка предложений по развитию проекта. Детальные требования приведены в разделе 4.2.8.

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

      4.1.1.1 Требования к взаимосвязям между компонентами системы и взаимосвязям систем с другими ИС

      При взаимодействии компонентов Системы в информационных потоках должно использоваться 2 способа взаимодействия:

      - синхронный;

      - асинхронный.

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

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

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

      Синхронное взаимодействие

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

      Базовым способом синхронного взаимодействия между компонентами системы должен быть обмен JSON сообщениями, построенный на базе архитектурного стиля проектирования REST.

      Данное взаимодействие обеспечивает:

      - высокую скорость обмена данными между компонентами системы;

      - масштабируемость компонента системы.

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

      - модуль вызывается в рамках работы пользователя и UI какой-либо подсистемы и результат запроса должен быть предоставлен ему немедленно;

      - модуль вызывается в рамках проверки процесса, которому данные от модуля нужны немедленно (к примеру, в момент проверки прав доступа к объектам подсистемы);

      - в потоках, обеспечивающих обмен критически важными данными.

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

      Каждая подсистема должна быть разбита, как минимум, на 2 слоя реализации:

      1. Слой модулей подсистемы – обеспечивает полный набор методов для управления системой. Используется администратором системы и GUI системы.

      2. Интеграционный слой – обеспечивает набор методов для взаимодействия подсистемы с другими подсистемами. Данный слой инкапсулирует внутреннюю логику подсистемы от внешних пользователей, а также может обеспечивать агрегацию и оркестрацию данных в подсистеме.

      Асинхронное взаимодействие

      Обмен сообщениями между подсистемами осуществляется через очереди сообщений. Каждому сообщению должен присваиваться идентификатор сообщения. В случае наличия ответа на сообщение, ответ должен содержать идентификатор исходного сообщения.

      Данное взаимодействие обеспечивает:

      - высокую отказоустойчивость обмена данными между компонентами системы;

      - масштабируемость компонента системы.

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

      - модули обмениваются значимой информацией для бизнеса, потеря которой неприемлема с точки зрения бизнес-процессов Заказчика;

      - обмен большим объемом данных (для обеспечения скорости обработки запросов от пользователя).

      Формат сообщений: XML, JSON.

      Аутентификация сообщений

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

      Взаимодействие с внешними системами

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

      4.1.1.2 Требования к режимам функционирования системы

      Система должна обеспечивать функционирование в следующих режимах:

      - Штатный режим – основной режим функционирования, при котором обеспечивается выполнение функций, предусмотренных разделом 4.2. В основном режиме Система должна функционировать в бесперебойном режиме 24 часа в сутки в течение всего календарного года, за исключением случаев плановых мероприятий по обслуживанию/обновлению Системы (сервисный режим).

      - Сервисный режим – режим, который используется для сопровождения, в том числе для изменения конфигурации, параметров работы, настроек, выполнения регламентированного обслуживания программно-технических средств Системы. В этом режиме допускается недоступность части функций Системы.

      - Аварийный режим – режим, в котором нарушается работоспособность отдельных или всех функций Системы.

      Описание условий функционирования Системы в каждом из упомянутых выше режимов должно быть приведено в Руководстве администратора.

      4.1.1.3 Требования по диагностированию системы

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

      4.1.1.4 Перспективы развития, модернизации системы

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

      Архитектура Системы должна обеспечивать возможность интеграции со сторонними ИС, масштабирование сервисов как по составу, так и по нагрузке на сервисы, обеспечивать возможность подключения сервисов сторонних разработчиков.

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

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

      4.1.2 Требования к архитектуре системы

      4.1.2.1 Требования к общей архитектуре

      Система должна быть масштабируемой и иметь средства адаптации к изменениям бизнес-процессов.

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

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

      Архитектура Системы должна обеспечивать:

      отказоустойчивость за счет использования современных технологий кластеризации и виртуализации, замены компонентов без остановки работы Системы;

      надежность, работоспособность и высокую доступность за счет:

      ○ реализации функциональности Системы в виде изолированных, слабо связанных микросервисов;

      ○ применения инструментов мониторинга и прогнозирования отказов и сбоев;

      ○ динамического масштабирования микросервисов при изменении нагрузки;

      обеспечение возможности изменения и применения настроек Системы без остановки работы Системы;

      возможность расширения функциональности Системы путем внедрения дополнительных подсистем;

      возможность параллельной разработки отдельных подсистем разными командами и независимого ввода в эксплуатацию подсистем без остановки Системы;

      каждый микросервисов Системы должен поддерживать горизонтальное масштабирование независимо от других микросервисов и быть полностью подготовлен к развертыванию в docker-контейнерах.

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

      4.1.2.2 Требования к технологической структуре

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

      Интеграционные сервисы должны:

      документироваться в виде WSDL либо Swagger описаний.

      обеспечивать обратную совместимость в пределах как минимум одной мажорной версии.

      4.1.2.3 Требования к платформе разработки

      При выборе платформы для реализации бизнес-логики Системы необходимо учитывать следующие требования:

      открытый код реализации среды исполнения;

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

      кроссплатформенность (поддержка Windows и Linux окружений);

      наличие внешних библиотек, реализованных на языках программирования платформы и предназначенных для:

      ○ реализации интеграционных сценариев;

      ○ реализации бизнес-процессов с сохранением состояния;

      ○ работы с базами данных (как РСУБД, так и НСУБД);

      ○ работы с брокерами сообщений;

      ○ работы со структурами данных JSON и XML;

      ○ обеспечения авторизации и аутентификации;

      ○ реализации SOAP и REST взаимодействия.

      поддержки в части сборки кода одним из средств автоматизации:

      ○ Maven;

      ○ Gradle;

      ○ SBT;

      ○ Любым другим, имеющим открытый исходный код и поддерживающим управление зависимостями.

      поддержка в части статического анализа кода любым промышленно используемым средством, имеющим открытый исходный код;

      поддержка любой промышленно используемой среды разработки, имеющей открытый исходный код.

      Платформа для реализации логики пользовательского интерфейса Системы должна обеспечивать открытый код реализации среды исполнения.

      4.1.2.4 Требования к организации среды развертывания

      Среда развертывания микросервисов модулей Системы должна поддерживать оркестрацию контейнеров (CLI либо аналогичную реализацию) за счет использования встроенного в платформу функционала либо внешнего продукта.

      Среда развертывания должна обеспечивать возможность встраивания средств обеспечения контроля безопасности контейнеров за счет поддержки соответствующего API.

      Среда развертывания микросервисов должна предоставлять инструменты:

      Управления зависимостями между микросервисами.

      Управления схемами постепенной доставки обновлений.

      Управления количеством одновременно работающих экземпляров микросервиса.

      Управления сетевой доступностью микросервисов посредством встроенного функционала либо подключаемых модулей.

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

      4.1.2.5 Требования к организации сборочного конвейера

      При создании сборочного конвейера и выбора технологий его организации предъявляются следующие базовые требования:

      - открытый код реализации среды исполнения;

      - поддержка доставки собранных артефактов в среду развертывания Системы;

      - поддержка взаимодействия CI/CD конвейера с механизмами управления схемами постепенной доставки обновлений.

      Рисунок 1 – Модель ветвления GitFlow

      Все изменения в рамках проекта должны вестись в ветке Develop. После того, как разработчик сделал commit в ветку Develop должен автоматически запускаться сценарий, который из исходного кода собирает артефакт в виде docker-контейнера и обогащает его версией. Далее артефакт должен загружаться в систему хранения артефактов. Если предыдущий шаг закончился успешно, должен выполняться шаг развертывания: передается команда по API на систему оркестрации контейнеров, которая содержит в себе аргументы с новой версией сервиса к развертыванию. Процесс развертывания должен происходить бесшовно, т. е. не должна прерываться работа текущего бизнес-функционала Системы.

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

      Таблица 1 – Модель ведения веток

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

      4.1.2.6 Требования к организации среды исполнения

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

      4.1.3 Требования к локализации системы

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

      В рамках разработки предложений по функциональным возможностям пользовательского интерфейса, Исполнитель должен сформировать критерии, по которым определяется требование к мультиязычности (на государственных языках государств – членов ЕАЭС) отдельных интерфейсов Системы.

      В рамках формирования требований к функциональному наполнению и инфраструктуре ННК и разработке требований к сервисам, Исполнителем должны быть определены перечни интерфейсов, реализуемых в мультиязычном (на государственных языках государств – членов ЕАЭС) формате.

      Исключения могут составлять только системные сообщения, не подлежащие русификации.

      4.1.4 Требования к численности и квалификации персонала системы и режиму его работы

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

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

      Пользователи Системы должны обладать квалификацией, обеспечивающей, как минимум:

      - базовые навыки работы на персональном компьютере с современными операционными системами (клавиатура, мышь, управление окнами и приложениями, файловая система);

      - базовые навыки использования интернет-браузера (настройка типовых конфигураций, установка подключений, доступ к web-сайтам, навигация, формы и другие типовые интерактивные элементы web-интерфейса);

      - знание основ информационной безопасности.

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

      Режим работы персонала должен быть определен в рабочей документации.

      4.1.5 Требования к нагрузке на систему

      Система должна обеспечивать масштабирование до указанных в таблице ниже целевых значений.

      Таблица 2. Нагрузочные показатели Системы

      Нагрузочные показатели определяются Исполнителем в ходе проектирования Системы и указываются в Пояснительной записке к техническому проекту.

      Система должна обеспечивать показатели производительности не ниже представленных в таблице ниже.

      Таблица 3. Показатели производительности Системы

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

      4.1.6 Требования к доступности и надежности

      Время восстановления Системы после отказа не должно превышать 4 часа.

      Полное резервное копирование данных Системы – не реже, чем 1 раз в 7 дней.

      Частичное (накопительное) резервное копирование данных Системы – не реже, чем 1 раз в 24 часа.

      Максимальная потеря данных при восстановлении из резервной копии – не более, чем последние 24 часа до момента сбоя.

      Восстановление Системы должно осуществляться путем восстановления Системы из резервной копии.

      Восстановление работы клиентских рабочих мест должно осуществляться путем переустановки общего и специального программного обеспечения.

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

      Аварийные ситуации делятся на следующие группы:

      - отказ технических средств Системы;

      - сбой программного обеспечения;

      - отсутствие сетевого доступа между рабочими местами и серверной частью Системы.

      В целом надежность функционирования Системы должна обеспечиваться:

      - использованием технических средств (ТС) повышенной отказоустойчивости;

      - защитой ТС от кратковременных перебоев в электропитании источниками бесперебойного питания (ИБП);

      - соблюдением требований производителей используемого программного обеспечения и технических средств по совместимости и режимов эксплуатации.

      Надежность серверного оборудования Системы должна обеспечиваться за счет дублирования основных элементов аппаратной платформы сервера: оперативная память, жесткие диски, блоки питания, платы ввода/вывода, вентиляторы.

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

      4.1.7 Требования к информационной безопасности

      Защита информации от несанкционированного должна быть реализована с учетом нормативно-технической и методической документации Комиссии и государств-членов.

      В Системе будет обрабатываться информация, не содержащая сведений ограниченного доступа.

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

      Для управления доступом к информации и функциональным возможностям Системы должна использоваться ролевая модель доступа.

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

      Неавторизованный пользователь не должен иметь доступа к специализированным функциям Системы.

      Для обеспечения безопасности при взаимодействии с ИИС Союза, сервисами Системы, национальными сервисами, разработанными государствами-членами и хозяйствующими субъектами должны поддерживаться следующие виды взаимодействия:

      - переход между приложениями с использованием защищенного протокола HTTPS;

      - обмен данными заданной структуры по утвержденным протоколам.

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

      Проектпроектные решения по информационной безопасности и СЗИ предоставляются и настраиваются Заказчиком и не являются предметом настоящего технического задания.

      4.1.8 Требования к эргономике и технической эстетике

      GUI пользователя Системы должен удовлетворять следующим требованиям:

      - обеспечивать выполнение функций Систем, требования к которым приведены в разделе 4.2, с минимальным количеством переключений между окнами и формами;

      - все сообщения об успешном выполнении или возникающих ошибках должны нести полную информацию и, при необходимости, рекомендации к устранению.

      Экранные формы Системы должны быть спроектированы с учетом следующих требований к мобильности и унификации:

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

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

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

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

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

      - страницы и размещенные на них формы и прочие элементы должны корректно отображаться при масштабировании стандартными средствами браузера;

      - должны использоваться шрифты без засечек;

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

      - графический интерфейс Системы не должен требовать использование проприетарных технологий (например, flash, silverlight).

      4.1.9 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

      4.1.9.1 Условия и регламент (режим) эксплуатации

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

      Условия, режим эксплуатации, виды и периодичность обслуживания технических средств Системы определяются требованиями поставщиков технических средств и должны быть описаны в Руководстве администратора.

      4.1.9.2 Требования к регламенту обслуживания

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

      ежедневное/еженедельное техническое обслуживание (при необходимости);

      месячное техническое обслуживание;

      полугодовое техническое обслуживание;

      годовое техническое обслуживание.

      4.1.10 Требования к сохранности информации при авариях

      Сохранность информации, хранящейся в Системах, должна быть обеспечена в случае наступления следующих событий:

      Аварийное отключение питания;

      Сбой технических и программных средств, не приводящий к потере целостности файловой системы.

      Должна быть обеспечена целостность БД при сбоях в проведении транзакций.

      Одновременный выход из строя двух жестких дисков дискового массива не должен сказываться на работоспособности Систем.

      Требования к резервному копированию данных Систем должны быть приведены в Руководстве администратора.

      Сохранность информации должна обеспечиваться совокупностью организационно-технических мер при работе Системы, а именно:

      - регулярным резервным копированием;

      - контролем целостности данных;

      - размещением хранилищ данных на отказоустойчивых технических средствах;

      - ограничением доступа к физическим хранилищам данных только администраторам Системы.

      4.1.11 Требования по стандартизации и унификации

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

      Интерактивные средства редактирования информации в Системе должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы и поиска:

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

      Экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;

      Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;

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

      Все поясняющие надписи в экранных формах, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть выполнены в соответствии с требованиями раздела 4.1.3.

      4.2 Требования к функциям

      4.2.1 Требования к разработке методологии цифровой трансформации

      В рамках разработки методологии цифровой трансформации должны быть оказаны следующие услуги:

      1. Формирование предложений по функциональным возможностям пользовательского интерфейса проекта на основании интервью с пользователями разрабатываемых сервисов.

      2. Анализ существующих практик и формирование целевых правил и рекомендаций для целей реализации проекта.

      3. Рассмотрение имеющихся справочников и классификаторов, подготовка предложений по актуализации и(или) дополнению в части технического регулирования Единой системы нормативно-справочной информации (НСИ) Союза.

      4. Проведение оценки представления технических регламентов, перечней стандартов для перевода в машиночитаемый формат.

      5. Формирование перечня объектов для апробации технических решений, необходимых для реализации проекта.

      6. Анализ и выбор классификатора(ов) продукции для целей цифровой трансформации Технического регулирования, проведение работ по обеспечению верификации предлагаемых методологий идентификации продукции по ее описанию.

      7. Разработка правил (инструкций) написания (перевода существующего) текста технического регламента в машиночитаемый формат.

      8. Разработка правил (инструкций) разметки перечней стандартов в привязке к выбранному(ым) классификатору(ам) продукции в рамках проекта.

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

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

      11. Разработка методических рекомендаций по формированию обязательных требований к продукции в среде сервиса проекта по разработке и внесению изменений в технические регламенты Союза.

      12. Разработка требований к внешним сервисам для их верификации и принятия решения о подключении к проекту.

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

      4.2.1.1 Требования к формированию предложений по функциональным возможностям пользовательского интерфейса проекта на основании интервью с пользователями разрабатываемых сервисов

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

      - сформирован перечень типов пользователей;

      - сформирован перечень интервьюируемых пользователей;

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

      4.2.1.2 Требования к анализу существующих практик и формирование целевых правил и рекомендаций для целей реализации проекта

      В рамках оказания услуг по данному пункту должны быть получены следующие результаты:

      - анализ существующей практики, которая должна показать комплекс действующих на данный момент правил и рекомендаций с указанием положений, которые необходимо изменить для целей реализации проекта;

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

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

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

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

      Предложения должны обеспечивать возможность использования Единой системы НСИ Союза для целей цифровой трансформации системы технического регулирования.

      4.2.1.4 Требования к проведению оценки представления технических регламентов, перечней стандартов для перевода в машиночитаемый формат

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

      - формирование перечня типов документов и определение положений, требующих оцифровки;

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

      - выделение типов элементов требований и описание их представления в машиночитаемом формате;

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

      - разработка методологии разметки.

      4.2.1.5 Требования к формированию перечня объектов для апробации технических решений, необходимых для реализации проекта

      В рамках оказания услуг по данному пункту должны быть должен быть сформирован закрытый перечень объектов регулирования для апробации технических решений, необходимых для реализации проекта (технические регламенты, перечни стандартов, наименование типов продукции и т.п.).

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

      4.2.1.6 Требования к анализу и выбору классификатора(ов) продукции для целей цифровой трансформации Технического регулирования, проведение работ по обеспечению верификации предлагаемых методологий идентификации продукции по ее описанию

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

      - выбор и обоснование выбора классификатора в качестве целевой системы идентификации продукции;

      - формирование методологии идентификации продукции, включая идентификацию внутри кода;

      - описание механизма "подбора кода классификатора по наименованию продукции, включая требования к набору данных для обучения;

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

      4.2.1.7 Требования к разработке правил (инструкций) написания (перевода существующего) текста технического регламента в машиночитаемый формат

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - разработка ролевой модели участников процесса написания (перевода существующего) текста технического регламента в машиночитаемый формат;

      - создание набора инструкций для каждой роли.

      4.2.1.8 Требования к разработке правил (инструкций) разметки перечней стандартов в привязке к выбранному(ым) классификатору(ам) продукции в рамках проекта

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - разработка ролевой модели участников процесса разметки перечней стандартов в привязке к выбранному(ым) классификатору(ам) продукции в рамках проекта;

      - создание набора инструкций для каждой роли.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - формирование перечня документов для перевода в цифровой формат в рамках проекта;

      - формирование дорожной карты перевода документов в цифровой формат;

      - разработка набора инструкций по переводу существующих документов в цифровой формат, включая регламенты выявления и обработки однозначно не оцифровываемых и частично не оцифровываемых элементов документов;

      - разработка регламента верификации оцифрованных документов.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - описание текущих бизнес-процессов;

      - разработка целевых бизнес-процессов;

      - анализ НПА;

      - анализ актов, входящих в право Союза, в части необходимости разработки и внесения изменений в технические регламенты Союза;

      - разработка проектов актов о внесении изменений в право Союза в части целевых правил (рекомендаций) для целей цифровой трансформации системы технического регулирования.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

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

      - подготовка набора организационно-технических мероприятий для целей внедрения разрабатываемых методических рекомендаций;

      - формирование функциональных требований для роли "Разработчик ТР ТС" и "Разработчик перечней стандартов", в том числе привлекаемых сторонних организаций;

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

      4.2.1.12 Требования к разработке требований к внешним сервисам для их верификации и принятия решения о подключении к проекту

      В рамках оказания услуг по данному пункту должен быть разработан комплект документов "Типовое соглашение об интеграции".

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

      В рамках оказания услуг по данному пункту должна быть проведена актуализация и, при необходимости, взаимоувязка результатов оказания услуг по п.п. 4.2.1.1-4.2.1.12.

      В рамках реализации данного пункта могут быть актуализированы результаты работ по п.п. 4.2.1.1-4.2.1.12

      4.2.2 Требования к разработке методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - Подготовка методической документации наднационального компонента и разрабатываемых сервисов, проектов актов Комиссии (при необходимости);

      - Разработка положений о ННК, разрабатываемых сервисах и порядка взаимодействия с единой системой нормативно-справочной информации Союза;

      - Выработка модели присоединения третьих стран и других негосударственных участников к сервису;

      - Подготовка пакета документов для всех типов пользователей проекта.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

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

      - разработка проектов методической документации ННК и разрабатываемых сервисов, проектов актов Комиссии.

      4.2.2.2 Требования к разработке положений о ННК, разрабатываемых сервисах и порядка взаимодействия с единой системой нормативно-справочной информации Союза

      В рамках оказания услуг по данному пункту должны быть разработаны:

      - положение о наднациональном компоненте, разрабатываемом в рамках раздела 4.2.3;

      - положения о разрабатываемых в рамках разделов 4.2.4 – 4.2.6 сервисах в рамках;

      - порядок взаимодействия с единой системой нормативно-справочной информации Союза.

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

      4.2.2.3 Требования к выработке модели присоединения третьих стран и других негосударственных участников к сервису

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

      4.2.2.4 Требования к подготовке пакета документов для всех типов пользователей проекта

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

      4.2.3 Требования к наднациональному компоненту

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - Разработка требований к функциональному наполнению и инфраструктуре ННК

      - Разработка технического проекта ННК

      - Разработка программного обеспечения ННК

      4.2.3.1 Состав подсистем наднационального компонента

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

      Наднациональный компонент должен включать в себя следующие подсистемы:

      - подсистема идентификации пользователей и управления их функциональными ролями;

      - подсистема хранения данных;

      - подсистема интеграции и взаимодействия с ИИС Союза;

      - подсистема пользовательского интерфейса;

      - прочие подсистемы.

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

      Детальные требования к наднациональному компоненту должны быть разработаны Исполнителем в рамках разработки требований к функциональному наполнению и инфраструктуре ННК.

      4.2.3.2 Описание автоматизируемого процесса

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

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

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

      Средства аутентификации и авторизации должны позволять управлять ролевой моделью доступа пользователя к функциональным возможностям Системы и обеспечивать сквозную авторизацию.

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

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

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

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

      Должна быть обеспечена возможность интеграции с внешними модулями аутентификации и авторизации, используя открытые стандарты аутентификации и авторизации (OAuth, OpenID).

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

      4.2.3.2.2. Требования к подсистеме хранения данных

      Подсистема хранения данных должна обеспечивать хранение структурированных и неструктурированных данных, ведение НСИ Системы и должна, в том числе, включать в себя:

      - модуль управления системными справочниками (интегрированный с НСИ ИИС Союза);

      - классификатор продукции, подлежащей техническому регулированию;

      - каталог сервисов;

      - структурированное хранилище технических регламентов и перечней стандартов;

      - неструктурированное хранилище данных.

      Модуль управления системными справочниками должен обеспечивать как ведение внутренних справочников Системы, так и получение справочников из внешних ИС. Перечень внешних справочников (не более 10 справочников) определяется Исполнителем в рамках разработки требований к функциональному наполнению и инфраструктуре ННК. Организационный доступ к внешним справочникам предоставляется Заказчиком.

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

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

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

      Каталог сервисов должен позволять управлять сервисами, предоставляемыми Системой, в том числе:

      - вести перечень предоставляемых Системой сервисов;

      - обеспечивать версионность предоставляемых Системой сервисов;

      - вести паспорт сервиса, предоставляемого Системой.

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

      Хранение непосредственно данных технических регламентов и перечней стандартов может быть реализовано в неструктурированном виде.

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

      4.2.3.2.3 Требования к подсистеме интеграции и взаимодействия с ИИС Союза

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

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

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

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

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

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

      4.2.3.2.4 Требования к подсистеме пользовательского интерфейса

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

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

      В рамках подсистемы пользовательского интерфейса должны быть предусмотрены личные кабинеты внешних пользователей (потребителей) Системы и личные кабинеты Заказчика и/или Оператора Системы.

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

      В рамках публичного портала должно быть предусмотрено сохранение истории действий пользователей.

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

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

      API-интерфейс для интеграции информационных систем пользователей с Системой должен быть разработан с учетом требований разделов 4.1.1.1, 4.1.2 Технического задания.

      В рамках API-интерфейса для интеграции информационных систем пользователей с Системой должны быть разработаны шаблоны интеграционных сервисов с авторизацией и без авторизации.

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

      4.2.3.2.5 Требования к прочим подсистемам

      В рамках разработки требований к функциональному наполнению и инфраструктуре ННК Исполнитель должен определить перечень прочих подсистем ННК. При определении перечня, назначения и требований к прочим подсистемам, Исполнитель должен учитывать требования к архитектуре Системы, определенные в разделе 4.1.2.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

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

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

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

      4.2.4.1 Перечень функций, подлежащих автоматизации

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

      - процесс ведения единого перечня продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

      - процесс инициации и согласования изменений в единый перечень продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

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

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

      4.2.4.2 Описание автоматизируемого процесса

      4.2.4.2.1 Требования к автоматизации процесса ведения единого перечня продукции, в отношении которой устанавливаются обязательные требования в рамках Союза

      В рамках автоматизации процесса ведения единого перечня продукции, в отношении которой устанавливаются обязательные требования в рамках Союза, в том числе, должны быть реализованы:

      - ведение единого перечня продукции, в отношении которой устанавливаются обязательные требования в рамках Союза в соответствии с Решением Комиссии Таможенного союза от 28.01.2011 № 526;

      - ведение версионности перечня продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

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

      4.2.4.2.2 Требования к автоматизации процесса инициации и согласования изменений в единый перечень продукции, в отношении которой устанавливаются обязательные требования в рамках Союза

      В рамках автоматизации процесса инициации и согласования изменений в единый перечень продукции, в отношении которой устанавливаются обязательные требования в рамках Союза, в том числе, должны быть реализованы:

      - автоматизация процесса сбора заявок на изменения в единый перечень продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

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

      4.2.4.3 Участники автоматизируемого процесса

      Участниками автоматизированного процесса являются:

      - департамент технического регулирования Комиссии;

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

      - органы по стандартизации и техническому регулированию государств–членов Союза;

      - физические и юридические лица, инициирующие изменения в единый перечень продукции, в отношении которой устанавливаются обязательные требования в рамках Союза;

      - разработчики технических регламентов и перечней стандартов.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - Разработка требований к сервису разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов Союза

      - Разработка технического проекта сервиса разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов Союза

      - Разработка программного обеспечения сервиса разработки технических регламентов и перечней стандартов, необходимых для применения и исполнения требований технических регламентов Союза

      4.2.5.1 Перечень функций, подлежащих автоматизации

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

      - процесс разработки технических регламентов (изменений в них) и перечней стандартов в машиночитаемом формате;

      - процесс привязки требований к классификатору продукции;

      - процесс формирования метаданных технических регламентов и перечней стандартов;

      - процесс управления планом разработки технических регламентов Евразийского экономического союза и внесения изменений в технические регламенты Таможенного союза.

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

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

      4.2.5.2 Описание автоматизируемого процесса

      4.2.5.2.1 Требования к автоматизации процесса разработки технических регламентов (изменений в них) и перечней стандартов в машиночитаемом формате

      В рамках автоматизации процесса разработки технических регламентов (изменений в них) и перечней стандартов в машиночитаемом формате, в том числе, должны быть реализованы:

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

      - интерфейс визуального сравнения машиночитаемых данных о единых обязательных требованиях, установленных в технических регламентах Союза с печатной версией технических регламентов;

      - автоматизация процесса разработки, согласования и утверждения технических регламентов (изменений в них) и перечней стандартов в машиночитаемом формате;

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

      4.2.5.2.2 Требования к автоматизации процесса привязки требований к классификатору продукции

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

      - интерфейс привязки требований к классификатору продукции, подлежащей техническому регулированию (см. раздел 4.2.1.6, 4.2.3.2.2);

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

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

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

      - управление каталогом технических регламентов и перечней стандартов;

      - статусная модель технических регламентов и перечней стандартов;

      - возможность фильтрации и поиска по метаданным технических регламентов и перечней стандартов в рамках цифрового технического регулирование.

      4.2.5.2.4 Требования к автоматизации процесса управления планом разработки технических регламентов Евразийского экономического союза и внесения изменений в технические регламенты Таможенного союза

      В рамках автоматизации процесса управления планом разработки технических регламентов Евразийского экономического союза и внесения изменений в технические регламенты Таможенного союза, в том числе, должны быть реализованы:

      - автоматизация процесса формирования и внесения изменений в план разработки технических регламентов Евразийского экономического Союза в соответствии Решение Совета Евразийской экономической комиссии от 23 апреля 2021 г. № 57 "О плане разработки технических регламентов Евразийского экономического союза и внесения в них изменений";

      - автоматизация контроля исполнения плана разработки технических регламентов Евразийского экономического Союза;

      - автоматизация процессов в сфере технического регулирования (в том числе разработки и внесения изменений в технические регламенты Союза и др.) в соответствии с результатами работы в рамках раздела 4.2.1.10 ТЗ.

      4.2.5.3 Участники автоматизируемого процесса

      Участниками автоматизированного процесса являются:

      - Департамент технического регулирования Союза;

      - иные департаменты Союза, задействованные в процессе технического регулирования;

      - органы по стандартизации и техническому регулированию государств–членов Союза;

      - разработчики технических регламентов и перечней стандартов.

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

      В рамках оказания услуг по данному пункту должны быть осуществлены:

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

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

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

      4.2.6.1 Перечень функций, подлежащих автоматизации

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

      - процесс формирования хранилища данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений;

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

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

      Детальные требования к сервису формирования полного набора данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений должны быть разработаны Исполнителем в рамках разработки требований к сервису формирования полного набора данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений

      4.2.6.2 Описание автоматизируемого процесса

      4.2.6.2.1 Требования к автоматизации процесса формирования хранилища данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений

      В рамках автоматизации процесса формирования хранилища данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений, в том числе, должны быть реализованы:

      - выбор архитектуры хранилища данных с учетом требований к перспективам развития Системы (см. раздел 4.1.1.4);

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

      - формирование витрин данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений.

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

      В рамках автоматизации процесса предоставления данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений, в том числе, должны быть реализованы:

      - WEB-интерфейс доступа к витринам данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений;

      - API-интерфейс доступа к витринам данных об обязательных требованиях к продукции, формах оценки соответствия, правилах и методах исследований (испытаний) и измерений;

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

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

      4.2.6.3 Участники автоматизируемого процесса

      Участниками автоматизированного процесса являются:

      - потребители сведений об обязательных технических требованиях Союза.

      4.2.7 Требование к разработке программного обеспечения интерфейсов программных приложений для подключения внешних сервисов

      В рамках оказания услуг по данному пункту должны быть осуществлены:

      - Разработка и утверждение требований к сторонним сервисам, национальным сервисам и сервисам третьих стран, подключаемым к проекту

      - Разработка технического проекта интерфейсов программных приложений для подключения внешних сервисов

      - Разработка программного обеспечения интерфейсов программных приложений для подключения внешних сервисов

      Должен быть реализован набор сервисов, описанных в типовом соглашении об интеграции с внешними сервисами в соответствии требованиями разделов 4.1.1.1, 4.2.1.12, 4.2.2.3 и 4.2.3.2.3.

      Должен быть определен и разработан набор конкретных методов интеграционного взаимодействия для подключения внешних сервисов (не более 10 методов).

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

      Должен быть реализован механизм сбора статистики обращений к внешним сервисам через Систему.

      Должен быть реализован каталог внешних сервисов, должно быть реализовано управление каталогом внешних сервисов Системы.

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

      4.2.8 Требования к разработке предложений по развитию проекта

      В рамках оказания услуг по данному пункту должен быть разработан пакет документов, необходимых для инициации цифрового проекта, подготовленный в соответствии с Решением Коллегии Комиссии от 16 апреля 2019 г. № 58 включающие следующие документы:

      - бизнес-кейс, включающий в себя следующие разделы:

      ○ краткое описание проекта, цели проекта;

      ○ стратегическое соответствие (зависимость от других проектов и мероприятий, стратегические выгоды);

      ○ потребители результатов проекта;

      ○ проблемы и ожидаемые результаты;

      ○ бизнес-модель;

      - верхнеуровневый план мероприятий ("дорожная карта") - документ с описанием основных этапов реализации проекта с указанием сроков реализации, ожидаемых результатов и ответственных исполнителей;

      - концептуальный проект, включающий в себя следующие разделы:

      ○ краткое описание проекта;

      ○ цели проекта, рамки проекта;

      ○ ключевые результаты;

      ○ описание архитектуры (архитектурные принципы, бизнес-архитектура, информационная архитектура, архитектура приложений, технологическая архитектура);

      ○ аспекты безопасности;

      - технико-экономическое обоснование, включающее в себя следующие разделы:

      ○ краткое описание проекта;

      ○ цели проекта;

      ○ анализ рынка;

      ○ основные преимущества проекта;

      ○ техническая оценка проекта;

      ○ расчеты и оценка затрат, ресурсов, в том числе финансовых, эффектов и выгод проекта;

      ○ рекомендации по проектному финансированию;

      - описание продукта проекта;

      - описание формы взаимодействия сторон в рамках реализации проекта;

      - предложения по организации эксплуатации и развития проекта;

      - предложения по принципам монетизации коммерческих сервисов проекта, в том числе, внешних сервисов;

      - предложения по порядку финансирования Оператора Системы.

      4.3 Требования к видам обеспечения системы

      4.3.1 Требования к информационному обеспечению системы

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

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

      4.3.2 Требования к программному обеспечению системы

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

      При разработке Системы приоритет должен отдаваться использованию свободно распространяемого программного обеспечения.

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

      4.3.3 Требования к техническому обеспечению системы

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

      Технические средства Системы должно функционировать в режиме 24x7 в течение 365(366) дней в году, без учета времени, необходимого для проведения регламентированных работ.

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

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

      - для среды разработки в срок не позднее 3 календарных месяца после предоставления спецификации аппаратного обеспечения;

      - для тестовой среды в срок не позднее 3 календарных месяцев после предоставления спецификации аппаратного обеспечения;

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

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

5 Состав и содержание оказания услуг

      Примечание ИЗПИ!
      В пункт 5.1 предусмотрен в редакции решения Коллегии Евразийской экономической комиссии от 15.11.2022 № 176 (вступает в силу по истечении 30 календарных дней с даты его официального опубликования).

      5.1 Календарный план оказания услуг

      В Таблица 4 приведен Календарный план оказания услуг.

      Таблица 4. Календарный план оказания услуг

      По согласованию с Заказчиком, допускается сдача-приемка отдельных услуг, независимо от остальных услуг в рамках этапа. При этом стоимость такой услуги определяется исходя из заявки участника в форме "Предложения о стоимости оказания услуг по договору".

      5.2 Требования к оказанию услуг по каждой стадии

      5.2.1 Стадия "Разработка методологии цифровой трансформации"

      На данной стадии оказываются услуги по разработке методологии цифровой трансформации.

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

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

      В рамках реализации стадии:

      - производится, при необходимости, анализ международной практики;

      - производится, при необходимости, обследование ИТ-ландшафта Союза и стран-участниц в части имеющихся ИС и используемых классификаторов;

      - производится анализ действующих нормативно-правовых актов Союза и стран-участниц в сфере технического регулирования;

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

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

      - производится разработка шаблона отчетных документов по методологии цифровой трансформации по соответствующему подпункту раздела 4.2.1;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка методологии цифровой трансформации".

      Отчетные документы по методологии цифровой трансформации в соответствии с требованиями раздела 4.2.1. Технического задания.

      5.2.2 Стадия "Разработка методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам"

      На данной стадии оказываются услуги по разработке методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам.

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

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

      В рамках реализации стадии:

      - производится, при необходимости, анализ международной практики;

      - производится анализ действующих нормативно-правовых актов Союза и стран-участниц в сфере технического регулирования;

      - производится разработка шаблона методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка методической документации, положений и соглашений по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам".

      Методологическая документация, положения и соглашения по проекту, в том числе, по наднациональному компоненту и разрабатываемым сервисам в соответствии с требованиями раздела 4.2.2. Технического задания.

      5.2.3 Стадия "Разработка требований к функциональному наполнению компонента Системы"

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

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

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

      В рамках реализации стадии:

      - производится, при необходимости, обследование ИТ-ландшафта Союза в части имеющихся ИС;

      - производится анализ действующих нормативно-правовых актов Союза и стран-участниц в сфере технического регулирования;

      - проводится, при необходимости, интервьюирование потенциальных пользователей Системы;

      - производится, при необходимости, разработка и согласование с ключевыми пользователями Системы схем автоматизируемых бизнес-процессов;

      - производится, при необходимости, разработка и согласование с ключевыми пользователями Системы макетов экранных форм, отчетов, аналитических панелей;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка требований к функциональному наполнению компонента Системы".

      Частное техническое задание на компонент Системы.

      5.2.4 Стадия "Разработка технического проекта компонента Системы"

      На данном этапе оказываются услуги с целью формирования проектных решений по компонентам Системы.

      В рамках реализации стадии:

      - производится разработка технических решений компонента Системы на основании результатов разработки требований к функциональному наполнению компонента Системы.

      - производится разработка технических решений по системной архитектуре, на основании результатов исследования текущего ИТ-ландшафта;

      - производятся работы по разработке требований к интеграции со смежными ИС;

      - производится, по согласованию с Заказчиком, разработка прототипа компонента Системы с целью демонстрации проектных решений;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка технического проекта компонента Системы".

      Технический проект компонента Системы в составе:

      - проектные решения компонента Системы;

      - технические решения по системной архитектуре;

      - проектные решения по интеграции компонента Системы и смежных ИС;

      - требования (спецификация) к оборудованию, системному программному обеспечению и вычислительной инфраструктуре Системы.

      5.2.5 Стадия "Разработка программного обеспечения компонента Системы"

      На данной стадии, в пределах функциональных рамок технических требований, определенных на стадии "Разработка технического проекта компонента Системы", производится разработка технических решений компонентов Системы.

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

      В рамках реализации стадии:

      - производится разработка программного обеспечения компонентов Системы;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка программного обеспечения компонента Системы"

      Программное обеспечение компонента Системы.

      Рабочая документация в составе:

      - программа и методика испытаний (ПМИ);

      - руководство администратора (РА);

      - руководство пользователя (РП);

      - руководство по развертыванию компонента Системы.

      5.2.6 Стадия "Комплексное тестирование Системы"

      На данной стадии, в пределах функциональных рамок технических требований, определенных на стадии "Разработка технического проекта компонента Системы", производится процедура комплексного тестирования технических решений, разработанных в рамках стадии "Разработка программного обеспечения компонента Системы".

      В рамках реализации стадии:

      - производится комплексное тестирование разрабатываемого функционала Системы в соответствии с требованиями раздела 6.3. Если в результате комплексного тестирования выявлено несоответствие работы Системы ожидаемому результату или выявлена неполнота набора данных для тестирования, то контрольное тестирование признается неуспешным, а Исполнитель обязуется устранить выявленные недостатки. Вне зависимости от результатов тестирования оформляется соответствующий протокол.

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Приемочные испытания"

      Протокол комплексного тестирования Системы по разработанной эксплуатационной документации.

      Реестр замечаний, выявленных при комплексном тестировании Системы.

      Реестр предложений по доработке Системы.

      Протокол устранения замечаний по результатам комплексного тестирования (при необходимости).

      5.2.7 Стадия "Доработка программного обеспечения"

      На данной стадии, в пределах согласованного перечня задач их реестра предложений по доработке Системы, сформированного на стадии "Комплексное тестирование Системы" или на стадии "Опытная эксплуатация" производится доработка технических решений Системы.

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

      В рамках реализации стадии:

      - производится доработка программного обеспечения Системы;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка программного обеспечения компонента Системы"

      Доработанное программное обеспечение Системы.

      Доработанная рабочая документация в составе:

      - программа и методика испытаний (ПМИ);

      - руководство администратора (РА);

      - руководство пользователя (РП);

      - руководство по развертыванию компонента Системы.

      5.2.8 Стадия "Развертывание и конфигурирование"

      На данной стадии оказываются услуги по подготовке Системы к опытной эксплуатации.

      Услуги, оказываемые в рамках данной стадии:

      - производится разработка Программы проведения опытной эксплуатации, а также разработка необходимых проектов регламентов и других распорядительных документов;

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

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

      - разрабатывается программа инструктажа пользователей Системы и производится инструктаж пользователей и обслуживающего персонала;

      - в процессе обучения по работе с Системой производится фиксация устранение обнаруженных ошибок функционирования, а также уточнение ранее утвержденных проектных решений, рабочей документации и нормативной документации;

      - производятся работы по актуализации проектной документации (при необходимости);

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

      - разрабатывается проект регламента сопровождения Системы (при необходимости).

      Отчетные документы стадии "Развертывание и конфигурирование"

      Программа проведения опытной эксплуатации.

      Отчет о загрузке первичных данных, включая перенос исторических данных (при необходимости).

      Программа проведения инструктажа пользователей.

      регламента сопровождения Системы.

      Проект акта ввода Системы в опытную эксплуатацию.

      5.2.9 Стадия "Опытная эксплуатация"

      В рамках стадии "Опытная эксплуатация" выполняется эксплуатация Системы с использованием реальных данных в соответствии с программой проведения опытной эксплуатации. На время проведения опытной эксплуатации предъявляются следующие требования к режиму функционирования системы:

      - штатный режим – доступность функций системы 24 часа в день, 7 дней в неделю (24х7). Круглосуточный режим работы системы не требует организации круглосуточной работы пользователей и допускает работу пользователей в соответствии со штатным расписанием;

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

      - аварийный режим – Система переходит в данный режим при возникновении нештатной ситуации и невозможности штатной работы. Переход на штатный режим должен быть осуществлен в течение 2-х рабочих дней с момента перехода в аварийный режим (за исключением случаев сбоя аппаратной части комплекса).

      Сопровождение Системы осуществляется следующим образом:

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

      - вторая линия поддержки (консультации специалистов службы поддержки и конечных пользователей по операциям, описанным в Руководстве пользователя, Руководстве администратора, Техническом проекте, а также по нетиповым операциям, диагностика и устранение внештатных ситуаций) выполняется консультантами Исполнителя.

      Услуги, оказываемые в рамках данной стадии:

      - оказываются услуги по сопровождению опытной эксплуатации;

      - производится нагрузочное тестирование Системы;

      - в процессе эксплуатации Системы производится фиксация ошибок в журнале опытной эксплуатации и устранение обнаруженных ошибок функционирования Системы, а также уточнение ранее утвержденных проектных решений, рабочей документации, нормативной документации;

      - производятся работы по актуализации проектной документации (при необходимости);

      - производятся работы, изложенные в разделе 6.4.

      Отчетные документы стадии "Опытная эксплуатация"

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

      Актуализированная проектная и рабочая документация (при необходимости).

      Журнал опытной эксплуатации.

      Реестр предложений по доработке Системы.

      Протокол проведения опытной эксплуатации Системы.

      5.2.10 Стадия "Ввод в промышленную эксплуатацию"

      На данной стадии производятся работы по вводу в промышленную эксплуатацию Системы.

      Услуги, оказываемые в рамках данной стадии:

      - разработка проекта Распоряжения о вводе Системы в промышленную эксплуатацию;

      - производится подготовка Системы к промышленной эксплуатации (перенос настроек/разработок в продуктивный контур, подготовка рабочих мест конечных пользователей, уточнение записей пользователей и их ролей);

      - актуализируется, при необходимости, проект регламента сопровождения Системы (при необходимости);

      - разработка учебных материалов для пользователей Системы.

      Отчетные документы стадии "Ввод в промышленную эксплуатацию".

      Проект Распоряжения о вводе Системы в промышленную эксплуатацию.

      Программа обучения пользователей, с указанием формы обучения и требований к обучению.

      Учебные материалы в соответствии с программой обучения.

      Актуализированный, при необходимости, регламент сопровождения Системы.

      Проект акта ввода Системы в промышленную эксплуатацию.

      5.2.11 Стадия "Разработка предложений по развитию"

      На данной стадии осуществляются услуги по получению необходимых исходных данных по формированию предложений по развитию Системы.

      Услуги, оказываемые в рамках данной стадии:

      - производится, при необходимости, обследование ИТ-ландшафта Союза в части имеющихся ИС;

      - производится анализ действующих нормативно-правовых актов Союза и стран-участниц в сфере технического регулирования;

      - проводится, при необходимости, интервьюирование потенциальных пользователей Системы;

      - производится, при необходимости, разработка и согласование с ключевыми пользователями Системы схем автоматизируемых бизнес-процессов;

      - производится, при необходимости, разработка и согласование с ключевыми пользователями Системы макетов экранных форм, отчетов, аналитических панелей;

      - производится анализ результатов опытной эксплуатации Системы, предложений пользователей по развитию Системы;

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Разработка предложений по развитию".

      Пакет документов, необходимых для инициации цифрового проекта, в соответствии с требованиями раздела 4.8 Технического задания.

      5.2.12. Стадия "Сбор и подготовка контента"

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

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

      Услуги, оказываемые в рамках данной стадии:

      - производится подготовка перечня технических регламентов и перечней стандартов;

      - производится сопоставление требований технических регламентов и перечней стандартов конкретной продукции в соответствии с результатами работ по пункту 4.2.1.6;

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

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

      - производится разработка отчетных документов по стадии.

      Отчетные документы стадии "Сбор и подготовка контента".

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

      5.2.13 Стадия "Наполнение контентом"

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

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

      Услуги, оказываемые в рамках данной стадии:

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

      Отчетные документы стадии "Наполнение контентом".

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

6 Порядок контроля и приемки

      6.1 Общие положения

      Сдача-приемка оказанных услуг производится поэтапно в соответствии с календарным планом оказания услуг.

      Приемка результатов оказанных услуг оформляется актом сдачи-приемки оказанных услуг (далее – финансовый акт).

      Необходимым условием для подписания финансового акта является наличие должным образом оформленных технических актов и листов утверждения для каждой указанной в финансовом акте услуги.

      По согласованию с Заказчиком, допускается сдача-приемка отдельных услуг, независимо от остальных услуг в рамках этапа. При этом стоимость такой услуги определяется исходя из заявки участника в форме "Предложения о стоимости оказания услуг по договору".

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

      Технический акт подписывается уполномоченным представителем Заказчика при наличии полностью оформленного листа согласования на соответствующую услугу.

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

      Результаты оказания услуг рассматриваются ответственными представителями Заказчика в соответствии с распределением ответственности:

      - в части общих и функциональных требований;

      - в части требований к защите информации;

      - в части требований к информационно-коммуникационной инфраструктуре.

      Максимальный срок рассмотрения Заказчиком результатов оказания услуг определяется договором.

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

      Лист согласования, подписанный со стороны исполнителей, представляется Заказчику одновременно с результатами оказания соответствующей услуги.

      Ответственные представители Заказчика рассматривают представленные исполнителем материалы.

      Сбор подписей представителей Заказчика на листе согласования осуществляют представители Исполнителя.

      6.2 Требования к видам, составу, объему и методам испытаний системы

      Приемка Системы должна быть организована и проведена в соответствии с ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем".

      Виды, состав, объем, и методы испытаний Системы должны быть изложены в документе "Программа и методика испытаний" (ПМИ).

      Испытания Системы проводятся с целью проверки соответствия результатов работ требованиям Технического задания.

      Испытания могут проводиться как по Системе в целом, так и по отдельным подсистемам, в соответствии с календарным планом оказания услуг.

      Испытания представляют собой процесс проверки выполнения функций Систем, выявления и устранения недостатков в ПО Системы и документации.

      Для проверки выполнения функций Систем, установленных ТЗ, проводятся следующие виды испытаний, предусмотренные ГОСТ 34.603-92:

      - тестирование Системы (предварительные испытания);

      - опытная эксплуатация;

      - приемочные испытания.

      Испытания проводятся в сроки, установленные Календарным планом-графиком.

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

      Испытания проводятся Комиссией, формируемой Заказчиком. В состав комиссии включаются представители Заказчика, Исполнителя и, при необходимости, эксперты, привлеченные Заказчиком.

      6.3 Требования к проведению тестирования Системы (предварительных испытаний)

      Порядок проведения предварительных испытаний:

      1. Предварительные испытания Системы или отдельных подсистем в соответствии с календарным планом проводятся для определения ее работоспособности и принятии решения о возможности приемки Системы или отдельных подсистем в соответствии с календарным планом в опытную эксплуатацию.

      2. До начала предварительных испытаний Исполнитель должен:

      - Развернуть ПО Системы или отдельных подсистем в соответствии с календарным планом на тестовой среде, предоставляемой Заказчиком.

      - Настроить ролевую модель, предусмотрев группы пользователей и права каждой группы, в объеме проводимых испытаний.

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

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

      3. Требования и порядок проведения предварительных испытаний должны быть описаны в ПМИ, которую разрабатывает Исполнитель и согласовывает с Заказчиком в сроки, установленные Календарным планом.

      4. В рамках предварительных испытаний должно быть осуществлено функциональное тестирование – тестирование функциональности Системы или отдельных подсистем в соответствии с календарным планом на соответствие требованиям ТЗ.

      5. В рамках тестирования Системы должна быть предусмотрена возможность реализации автоматических тестов.

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

      7. При наличии замечаний (отклонений от требований, изложенных в ТЗ), зафиксированных в протоколе предварительных испытаний, Исполнитель обязан устранить замечания в согласованный с Заказчиком срок в рамках доработки Системы по итогам тестирования и провести повторные предварительные испытания.

      8. По результатам успешного завершения предварительных испытаний (отсутствие в протоколе предварительных испытаний критичных замечаний) подписывается акт приемки Системы или отдельных подсистем в соответствии с календарным планом в опытную эксплуатацию.

      9. По результатам тестирования Системы осуществляется доработка Системы в части задач, не предусмотренных настоящим ТЗ, в объеме, согласованном с Заказчиком.

      6.4 Требования к проведению опытной эксплуатации

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

      Порядок проведения опытной эксплуатации:

      1. Опытно-промышленная эксплуатация должна проводиться с целью проверки функционирования Системы, готовности персонала к работе в условиях функционирования Системы, изменения (при необходимости) документации и настроек Системы.

      2. Опытно-промышленная эксплуатация Системы должна проводиться на программно-аппаратном комплексе Заказчика, в соответствии с согласованной Заказчиком Программой проведения опытной эксплуатации.

      3. Срок проведения опытной эксплуатации указан в Календарном плане, но должен составлять не менее 10 (Десяти) рабочих дней.

      4. В ходе опытной эксплуатации должен вестись "Журнал опытной эксплуатации", в который заносятся сведения о функционировании Системы, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Перечисленные сведения фиксируются в "Журнале опытной эксплуатации" с указанием даты и ФИО лица, направившего упомянутые сведения.

      5. По окончании опытной эксплуатации составляется протокол проведения опытной эксплуатации, в котором приводится перечень необходимых доработок.

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

      7. В рамках опытной эксплуатации Исполнителем должно быть проведено нагрузочное тестирование. Нагрузочное тестирование – должно обеспечивать проверку выполнения нагрузочных показателей, приведенных в подразделе 4.1.5 ТЗ и должно проводиться в соответствии с Методикой нагрузочного тестирования, согласованной с Заказчиком. По результатам проведения нагрузочного тестирования Исполнителем должен быть подготовлен Отчет о проведении нагрузочного тестирования, который, помимо описания результатов тестирования, при необходимости должен содержать рекомендации по дооснащения программно-аппаратного обеспечения Системы

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

      Приемка результатов работ осуществляется в соответствии с Календарным планом оказания услуг по договору. Приемка результатов выполнения работ оформляется Актом сдачи-приемки работ по этапу.

      6.5 Требования к проведению приемочных испытаний

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

      2. В рамках приемочных испытаний должен быть выполнен функциональный экспресс-тест – валидация основной функциональности Системы после ее установки на продуктивную среду (доступ к продуктивной среде предоставляется Заказчиком).

      6.6 Требования к гарантии качества выполняемых работ

      Заказчик определяет период гарантийных обязательств на качество работ Исполнителя (гарантийный период) 12 месяцев с даты сдачи – приемки выполненных работ.

      6.6.1 Требования к объему гарантий качества оказываемых услуг

      В течение гарантийного периода Исполнитель обязан безвозмездно (без каких-либо расходов со стороны Заказчика) вносить необходимый объем изменений в документацию и программное обеспечение в целях устранения выявленных недостатков. Срок внесения указанных изменений и сдачи Заказчику должен составлять не более 22 (двадцати двух) рабочих дней с даты получения Исполнителем соответствующего поручения Заказчика.

      В случае наступления гарантийного случая Исполнитель обязан безвозмездно провести следующие гарантийные мероприятия:

      - внести изменения в комплект технической документации;

      - внести изменения в программное обеспечение (при необходимости);

      - провести переустановку программного обеспечения (при необходимости).

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

7 Требования к составу и содержанию услуг по подготовке объекта автоматизации к вводу системы в действие

      7.1 Развертывание и конфигурирование

      ПО, используемое для обеспечения функционирования Системы, должно быть установлено и сконфигурировано Исполнителем на аппаратном обеспечении, предоставленном Заказчиком в порядке, предусмотренным разделом 4.3.3.

      Конфигурирование ПО должно быть выполнено Исполнителем в соответствии с инструкциями, приведенными в "Руководстве администратора".

      Конфигурирование ПО должно быть выполнено для среды разработки, тестовой среды и продуктивной среды (в рамках ресурсов, предоставленных Заказчиком в соответствии с разделом 4.3.3).

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

      Исполнитель должен внести в Систему все справочники и классификаторы, необходимые для функционирования Системы.

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

      7.2 Требования к инструктажу персонала

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

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

      Исполнитель обязан провести инструктаж пользователей с учетом следующих требований:

      - инструктаж должен производиться с использованием видеоконференцсвязи или на рабочих местах ключевых пользователей;

      - продолжительность инструктажа согласуется с Заказчиком.

      Проведение инструктажа должно выполняться в следующем порядке:

      Исполнитель разрабатывает и направляет Заказчику не менее чем за 5 рабочих дней до начала проведения инструктажа на согласование программу инструктажа ключевых пользователей по вопросам использования Системы (далее – Программа инструктажа).

      Дата проведения инструктажа согласуется Исполнителем с Заказчиком не менее чем за 5 рабочих дней до начала проведения инструктажа.

      Исполнитель проводит инструктаж по вопросам использования Системы в соответствии с согласованной Программой инструктажа.

8 Требования к документированию

      Результаты работ в части документации передаются на бумажных (два экземпляра) и на машинных носителях (флеш-диск). Текстовые документы, передаваемые на машинных носителях, должны быть представлены в формате docx.

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

      Состав передаваемых на машинных носителях результатов работ оформляется ведомостью машинных носителей информации.

      Все материалы передаются с сопроводительными документами Исполнителя.

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

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

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

      8.1 Требования к документам по методологии цифровой трансформации

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

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

      8.2 Требования к методической документации, положениям и соглашениям по проекту

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

      Формат отчетных документов по методической документации, положениям и соглашениям по проекту должен быть согласован или скорректирован Заказчиком в течении 30 календарных дней с даты предоставления формата документа Исполнителем. Если в течении 30 календарных дней Заказчиком не предоставлены обоснованные замечания к формату документа по методической документации, положениям и соглашениям по проекту, данный формат отчетного документа считается согласованным.

      8.3 Требования к частному техническому заданию

      Частное техническое задание предназначено для детализации требований к компонентам Системы. Частное техническое задание должно быть разработано в Исполнителем согласно ГОСТ 34.602-89.

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

      Пояснительная записка к техническому проекту предназначена для описания проектных решений, обеспечивающих выполнение требований настоящего ТЗ, и должна быть разработана Исполнителем согласно ГОСТ 19.404-79 "Единая система программной документации (ЕСПД). Пояснительная записка. Требования к содержанию и оформлению" (далее – ГОСТ 19.404-79). При этом достаточный состав разделов Пояснительной записки к техническому проекту из числа разделов, предусмотренных ГОСТ 19.404-79, определяется Исполнителем по согласованию с Заказчиком.

      Детализация описания проектных решений, изложенных в Пояснительной записке к техническому проекту, должна соответствовать рекомендациям, предусмотренным ГОСТ Р ИСО/МЭК 12207-2010 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств".

      При описании в Пояснительной записке к техническому проекту реализации процессов, предполагающих выполнение последовательности работ или действий, необходимо проиллюстрировать описание реализации упомянутых процессов, а также информационных потоков с использованием нотации методологии IDEF0 в соответствии с Р 50.1.028-2001 и/или методологии BPMN 2.0 и/или методологии UML; выбор методологии при описании реализации тех или иных процессов в Пояснительной записке к техническому проекту определяется Исполнителем.

      В составе пояснительной записки к техническому проекту необходимо привести проектные решения подсистем Системы, в рамках которых, по каждой из подсистем, должны быть представлены:

      - Информационная и бизнес-архитектура;

      - Архитектура прикладных решений;

      - Состав методов программного интерфейса;

      - Последовательность взаимодействия прикладных компонентов подсистемы с другими подсистемами;

      - Модель данных подсистемы (при необходимости);

      - Описание исполняемых бизнес-процессов в нотации BPMN 2.0 (при необходимости).

      В составе пояснительной записки к техническому проекту необходимо привести технические решения по системной архитектуре, содержащие:

      - Общую архитектуру прикладных решений Системы;

      - Состав компонентов Системы;

      - Решения по взаимосвязи системы со смежными системами, обеспечению их совместимости;

      - Схему развертывания Системы.

      В составе пояснительной записки к техническому проекту необходимо привести проектные решения по интеграции Системы и смежных ИС. Должны быть представлены:

      - Общее описание интеграционного сервиса;

      - Последовательность взаимодействия прикладных компонентов подсистемы с внешними ИС;

      - Перечень методов интеграционного взаимодействия;

      - Описание каждого метода интеграционного сервиса.

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

      8.5 Требования к рабочей документации

      При разработке рабочей документации Исполнитель должен руководствоваться ГОСТ 19.101-77 "ЕСПД. Виды программ и программных документов" (далее – ГОСТ 19.101-77). При этом состав разделов документов определяется по согласованию с Заказчиком.

      При разработке Программы и методики испытаний (далее – ПМИ) Исполнитель должен руководствоваться ГОСТ 19.301-79 "ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению".

      В составе рабочей документации должны быть разработаны эксплуатационная и приемочная документация.

      Эксплуатационная документация в составе:

      - руководство пользователя;

      - руководство администратора;

      - руководство по развертыванию системы;

      - текст программных компонентов в исходном коде (исходные тексты программ);

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

      Приемочная документация (на Систему в целом или на отдельные подсистемы в соответствии с Календарным планом) в составе:

      - программа и методика испытаний;

      - протокол комплексного тестирования;

      - реестр замечаний, выявленных при комплексном тестировании Системы;

      - протокол устранения замечаний по результатам комплексного тестирования (при необходимости);

      - программа проведения опытной эксплуатации;

      - отчет о загрузке первичных данных, включая перенос исторических данных (при необходимости);

      - протокол проведения приемочных испытаний;

      - проект регламента сопровождения Системы;

      - программа инструктажа пользователей;

      - журнал опытной эксплуатации;

      - протокол проведения опытной эксплуатации Системы;

      - методика нагрузочного тестирования;

      - отчет проведения нагрузочного тестирования;

      - протокол проведения итоговых испытаний;

      - проект приказа о вводе Системы в промышленную эксплуатацию.