=== ФАЙЛ: Приложение № 1. Описание объекта закупки.docx | docs/0145200000426001424/Приложение № 1. Описание объекта закупки.pdf
УТВЕРЖДАЮ
Директор государственного казенного
учреждения Ленинградской области
«Центр энергосбережения и повышения
энергоэффективности Ленинградской
области»
___________________ Н.А. Лазаревич
(подпись)
«______»__________________20____г.
М.П.
ОПИСАНИЕ ОБЪЕКТА ЗАКУПКИ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития
Подсистемы «Учет потребления коммунальных ресурсов Ленинградской области»
Техническое задание на 89 листах
СОГЛАСОВАНО
СОГЛАСОВАНО
Председатель комитета по топливноэнергетическому комплексу
Ленинградской области
Председатель комитета цифрового
развития Ленинградской области
______
____________С.С. Морозов
(подпись)
«_____» _______________20____г.
___________________ А.С. Сытник
(подпись)
«_____» _______________20____г.
М.П.
М.П.
Санкт-Петербург
2026 г.
ОГЛАВЛЕНИЕ
Принятые термины и сокращения................................................................................. 6
1 Общие сведения............................................................................................................9
1.1 Полное наименование Подсистемы и ее условное обозначение.......................9
1.2 Заказчик Подсистемы............................................................................................ 9
1.3 Исполнитель работ................................................................................................. 9
1.4 Место выполнения работ.......................................................................................9
1.5 Нормативно-правовые акты обеспечения работ...............................................10
1.6 Плановые сроки начала и окончания работ по развитию Подсистемы..........12
1.7 Сведения об источниках и порядке финансирования работ............................12
2 Цели и назначение автоматизированной Подсистемы...........................................13
2.1 Цель создания Подсистемы.................................................................................13
2.2 Назначение Подсистемы......................................................................................13
3 Характеристики объекта автоматизации.................................................................15
3.1 Основные сведения об объекте автоматизации................................................15
3.2 Состав Подсистемы..............................................................................................16
4 Требования к автоматизированной Подсистеме.....................................................19
4.1 Требования к структуре Подсистемы в целом..................................................19
4.2 Требования к выполнению работ.......................................................................21
5 Требования к видам обеспечения............................................................................. 22
5.1 Требования к математическому обеспечению Подсистемы............................22
5.1.1 Требования к составу, структуре и способам организации данных................................22
5.1.2 Требования к информационному обмену между компонентами Подсистемы и со
смежными ИСиС............................................................................................................................23
5.1.3 Требования к информационной совместимости со смежными ИСиС............................23
5.1.4 Требования по применению систем управления базами данных....................................29
5.1.5 Требования к представлению данных в подсистеме.........................................................29
5.1.6 Требования к контролю, хранению, обновлению и восстановлению данных..............29
5.2 Требования к лингвистическому обеспечению Подсистемы..........................30
5.2.1 Требования к языкам, используемым в Подсистеме.........................................................30
5.2.2 Требования к способам организации диалога...................................................................30
5.2.3 Требования к разработке и использованию словарей, тезаурусов..................................30
5.2.4 Требования к описанию синтаксиса формализованного языка.......................................30
5.3
Требования к программному обеспечению Подсистемы............................30
5.3.1 Требования к составу и видам программного обеспечения.............................................30
5.3.2 Требования к выбору используемого программного обеспечения.................................31
5.3.3 Требования к разрабатываемому программному обеспечению.......................................31
2
5.3.4 Требования к покупным программным средствам...........................................................32
5.4 Требования к техническому обеспечению........................................................32
5.4.1 Требования к системно-технической инфраструктуре.....................................................32
5.4.2 Требования к автоматизированным рабочим местам.......................................................33
5.4.3 Требования к функциональным группам серверов...........................................................33
5.5 Требования к метрологическому обеспечению................................................34
5.6 Требования к организационному обеспечению................................................34
5.6.1 Требования к порядку организации работы при сбоях и нештатных ситуациях...........34
5.7 Требования к методическому обеспечению......................................................36
6 Общие технические требования к Подсистеме.......................................................37
6.1 Требования к надежности Подсистемы.............................................................37
6.2 Требования по конфиденциальности.................................................................38
6.3 Требования к эргономике и технической эстетике...........................................40
6.4 Требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов Подсистемы.......................................................................41
6.5 Требования к сохранности информации при авариях......................................42
6.6 Требования к защите от влияния внешних воздействий..................................43
6.7 Требования к патентной чистоте и патентоспособности.................................43
7 Состав и содержание работ по развитию подсистемы...........................................46
7.1 Требования к безопасности выполнения работ.................................................46
7.2 Требования к сроку и объему предоставления гарантий качества работ.......46
7.3 Требования к объему работ................................................................................. 47
8 Порядок развития автоматизированной Подсистемы............................................49
8.1 Порядок развития Подсистемы...........................................................................49
8.2 Разработка функциональной возможности выбора периода графика и
реестра в функциональном модуле «Контроль превышения фактического
теплопотребления от проектного» раздела «Энергоэффективность»...................51
8.2.1 Реализовать отображение данных за период «с, по» для раздела «График»..................51
8.2.2 Реализовать отображение данных за период для раздела Карта.....................................52
8.2.3 Реализовать отображение данных за период для раздела Реестр....................................52
8.2.4 Реализовать печатную форму отчета..................................................................................52
8.3 Разработка функциональной возможности выбора периода в модуле
«Контроль температурного графика» раздела «Энергоэффективность».............53
8.3.1 Реализовать отображение данных за период для раздела График...................................53
8.3.2 Реализовать отображение данных за период для раздела Карта.....................................54
8.3.3 Реализовать отображение данных за период для раздела Реестр....................................54
8.3.4 Реализовать печатную форму отчета..................................................................................54
8.4 Разработка печатной формы «Контроль температурного графика» по
объекту потребления..................................................................................................55
3
8.4.1 Реализовать возможность формировать отчет по конкретному объекту........................55
8.4.2 Добавить возможность формировать отчет «Контроль температурного графика» из
дерева объектов..............................................................................................................................56
8.5 Доработка модуля «Реестры» в разделе формирования отчетности
«Сверхнормативное потребление тепловой энергии», в части доработки выбора
района при формировании отчета............................................................................56
8.5.1 Добавить возможность выбора района...............................................................................56
8.5.2 Запретить выбирать головной прибор, если не указан объект головного прибора.......57
8.6 Добавление механизмов расчета рекомендуемого расхода для
температурных графиков...........................................................................................57
8.6.1 Разработка функции расчета рекомендуемого расхода для температурного графика на
обратном трубопроводе.................................................................................................................57
8.6.2 Разработка печатной формы для рекомендуемого расхода по объекту..........................58
8.7 Разработка интерактивного виджета на стартовой странице с
функциональной информацией по перерасходу тепловой энергии от
нормативного показателя в денежном выражении.................................................58
8.8 Доработка формирования отчета в модуле «Реестры», раздел «Превышение
лимитов потребления» в части выбора муниципального образования без
привязки к подключенным объектам.......................................................................59
8.9 О замене системы управления базами данных в целях импортозамещения и
повышения уровня защиты информации....................................................................59
9 Порядок контроля и приемки Подсистемы.............................................................61
9.1 Виды испытаний и внедрение доработанной Подсистемы..............................61
9.2 Проведение профилактических работ................................................................64
9.3 Передача исходных кодов...................................................................................64
9.4 Общие требования к приемке работ...................................................................65
9.5 Требования информационной безопасности при проведении работ по
развитию информационной системы.......................................................................67
9.5.1 Требования информационной безопасности..................................................67
9.5.2 Требования к наличию лицензий.....................................................................68
9.5.3 Требования к удаленному доступу..................................................................71
9.5.4. Требования к разработке организационных, организационно – технических
и распорядительных документов по информационной безопасности при
осуществлении развития ГИС ЛО...............................................................................72
9.5.5 Требования к моделированию угроз безопасности...........................................73
9.5.6 Требования к устранению уязвимостей.............................................................76
10 Требования к составу и содержанию работ по подготовке Подсистемы к вводу
в действие....................................................................................................................... 78
11 Требования к документированию...........................................................................79
12 Источники разработки.............................................................................................81
13 ПРИЛОЖЕНИЯ........................................................................................................83
4
5
Принятые термины и сокращения
Термин/ наименование
/сокращение
Подсистема
ИС
Контракт
Работы
Исполнитель
Пользователь
Подсистемы
Развитие Подсистемы
Мониторинг
Надежность Подсистемы
API
ПО
СУБД
Определение/ описание
Подсистема региональной государственной информационной
системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов
Ленинградской области»
Информационная система взаимосвязанная совокупность средств,
методов и персонала, используемых для сбора, хранения,
обработки, анализа и выдачи информации в интересах достижения
определённых целей
Государственный контракт на выполнение работ по развитию
Подсистемы региональной государственной информационной
системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов
Ленинградской области»
Работы по развитию Подсистемы региональной государственной
информационной системы жилищно-коммунального хозяйства
Ленинградской области «Учет потребления коммунальных
ресурсов Ленинградской области»
Юридическое / физическое лицо, индивидуальный
предприниматель, с которым Заказчиком заключен
Государственный контракт на выполнение работ по развитию
Подсистемы в соответствии с Федеральным законом № 44-ФЗ от
05.04.2013 года «О контрактной системе в сфере закупок товаров,
работ, услуг для обеспечения государственных и муниципальных
нужд»
Пользователями системы являются поставщики информации,
(указанные в пункте 24 и 25 Терминов и определений к
настоящему ООЗ, пользователи ГИС ТЭК), имеющие доступ к
Подсистеме и использующие ее функционал, органы
исполнительной власти, органы местного самоуправления,
ресурсоснабжающие организации
Деятельность по выполнению работ, необходимых для
обеспечения устойчивого функционирования Подсистемы,
актуализации функциональных возможностей Подсистемы
согласно функциональным требованиям
Процесс систематического или непрерывного сбора информации
о параметрах сложного объекта или процесса
Комплексное свойство системы сохранять во времени
в установленных пределах значения всех параметров,
характеризующих способность системы выполнять свои функции
в заданных режимах и условиях эксплуатации
API (интерфейс прикладного программирования) - описание
способов (набор классов, процедур, функций, структур или
констант), которыми одна компьютерная программа может
взаимодействовать с другой программой
Программное обеспечение
Система управления базами данных
6
ЦОД ЛО
АРМ
ГОСТ
Инцидент
Аутентификация
БД
Внешние системы
Время выполнения
ГАР
УПКР
Запрос
Идентификация
Конвертация данных
ОМС
ООЗ
Поставщики информации
РСО
Электронный запрос
АСКУЭ
ЕИС
ЕСИА
ЕСПД ЛО
ФСТЭК
Центр обработки данных правительства Ленинградской области
Автоматизированное рабочее место
Государственный стандарт
Любое событие, не являющееся частью стандартного (штатного)
использования Подсистемы, которое привело или могло привести
к прерыванию или невозможности использования Подсистемы
Процесс подтверждения прав на использование идентификатора
База данных - совокупность данных, организованных в
соответствии с концептуальной структурой, описывающей
характеристики этих данных и взаимоотношения между ними,
которая поддерживает одну или более областей применения
РГИС Энергосбережения Ленинградской области, прочие
информационные системы
Время, прошедшее с момента поступления Запроса до направления
уведомления пользователю о завершении работы по Запросу
Государственный адресный реестр, содержащий информацию об
адресах в муниципальном делении
Подсистема РГИС ЖКХ ЛО «Учет потребления коммунальных
ресурсов Ленинградской области»
Запрос, связанный с событием, которое не является частью
нормальной/текущей/операционной работы Подсистемы,
ситуация, в которой выявлен дефект или стабильно
повторяющиеся дефекты
Процесс распознавания субъекта в компьютерной системе при
помощи анализа его идентификатора
Преобразование данных из одного формата в другой, с
сохранением основного логически-структурного содержания
информации
Органы местного самоуправления Ленинградской области
Описание объекта закупки
Эксплуатанты зданий, органы местного самоуправления,
ресурсоснабжающие организации Ленинградской области, ЛОГКУ
«Центр энергосбережения и повышения энергоэффективности
Ленинградской области»
Ресурсоснабжающие организации
Запрос информации в рамках межведомственного взаимодействия
посредством API
Автоматизированная система коммерческого учёта электроэнергии
Единая информационная система в сфере закупок
Единая система идентификации и аутентификации
Единая сеть передачи данных Ленинградской области
Федеральная служба по техническому и экспортному контролю
7
Российской Федерации
ФИАС
ИСиС
ЭД
ОРД
МУ
ЦУС
ПЭВМ
JSON
Федеральная информационная адресная система
Информационные сети и системы
Эксплуатационная документация
Организационно-распорядительная документация
Муниципальное учреждение
Целевой уровень снижения энергопотребления
Персональная электронная вычислительная машина
Текстовый формат обмена данными
8
1
ОБЩИЕ СВЕДЕНИЯ
В настоящем документе представлено техническое задание на выполнение
работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития
Подсистемы «Учет потребления коммунальных ресурсов Ленинградской области».
1.1
Полное наименование Подсистемы и ее условное обозначение
Полное
наименование
информационной
Подсистемы:
региональная
государственная информационная система жилищно-коммунального хозяйства
Ленинградской области в части Подсистемы «Учет потребления коммунальных
ресурсов Ленинградской области».
Регистрационный номер ИС: 1-07-0-00-01.
Дата регистрации: 22.05.2018 г.
Краткое наименование: РГИС ЖКХ УПКР ЛО, Подсистема.
1.2
Заказчик Подсистемы
Заказчик, оператор: Государственное казённое учреждение Ленинградской
области
«Центр
энергосбережения
и
повышения
энергоэффективности
Ленинградской области» (далее – ГКУ ЛО «ЦЭПЭ ЛО»).
Функциональный заказчик – комитет по топливно-энергетическому
комплексу Ленинградской области (далее – комитет по ТЭК ЛО).
1.3
Исполнитель работ
Исполнитель определяется в соответствии с Федеральным законом от 5
апреля 2013 года № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ,
услуг для обеспечения государственных и муниципальных нужд».
1.4
Место выполнения работ
Санкт-Петербург и Ленинградская область. Подсистема развернута на
аппаратных мощностях ЦОД Правительства Ленинградской области по адресу
Выборгское шоссе, д. 503, корп. 12.
Адрес
заказчика:
ГКУ
ЛО
«ЦЭПЭ
ЛО»:
Санкт-Петербург
муниципальный округ Смольнинское вн.тер.г., Калужский пер., 3 А.
9
г.,
Адрес функционального заказчика: Комитет по ТЭК ЛО: г. СанктПетербург, ул. Смольного, д. 3.
1.5
Нормативно-правовые акты обеспечения работ
 Федеральный закон от 27.07.2006 г. № 149-ФЗ «Об информации,
информационных технологиях и о защите информации»;
 Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности
критической
информационной
инфраструктуры
Российской
Федерации»;
 Федеральный закон от 21.07.2014 № 209-ФЗ «О государственной
информационной системе жилищно-коммунального хозяйства»;
 Указ Президента Российской Федерации от 17.03.2008 г. № 351 «О
мерах по обеспечению информационной безопасности Российской
Федерации при использовании информационно-телекоммуникационных
сетей международного информационного обмена»;
 Указ Президента Российской Федерации от 30.03.2022 г. № 166 «О
мерах по обеспечению технологической независимости и безопасности
критической
информационной
инфраструктуры
Российской
Федерации»;
 Постановление Правительства Российской Федерации от 16.11.2015 г.
№ 1236 «Об утверждении правил формирования и ведения единого
реестра российских программ для электронных вычислительных машин
и баз данных и единого реестра программ для электронных
вычислительных машин и баз данных из государств - членов
евразийского экономического союза, за исключением российской
федерации»;
 Постановление Правительства Российской Федерации от 06.07.2015 №
676 «О требованиях к порядку создания, развития, ввода в
эксплуатацию,
эксплуатации
и
вывода
из
эксплуатации
государственных информационных систем, и дальнейшего хранения
содержащейся в их базах данных информации»;
10
 Постановление
Правительства
лицензировании
РФ
деятельности
от
03.02.2012
№
по
технической
79
«О
защите
конфиденциальной информации»;
 Областной закон Ленинградской области от 18.07.2016 № 60-оз
«О государственных
информационных
системах
Ленинградской
области»;
 Постановление Правительства Ленинградской области от 14.11.2013 №
395 «Об утверждении государственной программы Ленинградской
области «Цифровое развитие Ленинградской области»;
 Постановление Правительства Ленинградской области от 14.11.2013 №
400 «Об утверждении государственной программы Ленинградской
области "Обеспечение устойчивого функционирования и развития
коммунальной
и
инженерной
инфраструктуры
и
повышение
энергоэффективности в Ленинградской области»;
 Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении
Требований о защите информации, содержащейся в государственных
информационных
системах,
иных
информационных
системах
государственных органов, государственных унитарных предприятий,
государственных учреждений»;
 ГОСТ Р 50922-2006 «Защита информации. Основные термины и
определения»;
 ГОСТ
Р
56545-2015
«Защита
информации.
Уязвимости
информационных систем. Правила описания уязвимостей»;
 ГОСТ
Р
59793-2021
«Информационные
технологии.
Комплекс
стандартов на автоматизированные системы. Автоматизированные
системы. Стадии создания»;
 ГОСТ
Р
стандартов
59792-2021
на
«Информационные
автоматизированные
автоматизированных систем».
11
технологии.
системы.
Виды
Комплекс
испытаний
Объектами автоматизации являются процессы, связанные с учетом
потребления коммунальных ресурсов объектами Ленинградской области и анализ
эффективности потребления коммунальных ресурсов, и передача накопленной
информации во внешние системы.
1.6
Плановые сроки начала и окончания работ по развитию Подсистемы
Срок выполнения работ: в соответствии с разделом 8.1 ООЗ:
Начало: С момента заключения государственного контракта.
Окончание: не позднее 14.12.2026 г.
1.7
Сведения об источниках и порядке финансирования работ
Источник
финансирования
работ
по
развитию
региональной
государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области в части развития Подсистемы «Учет потребления
коммунальных ресурсов Ленинградской области» – бюджет Ленинградской
области (в рамках исполнения Областного закона Ленинградской области от
20.12.2024 № 178-оз «Об областном бюджете Ленинградской области на 2025 год и
на плановый период 2026 и 2027 годов»).
12
2
ЦЕЛИ И НАЗНАЧЕНИЕ АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЫ
Подсистема региональной государственной информационной системы
жилищно-коммунального хозяйства «Учет потребления коммунальных ресурсов
Ленинградской области» предназначена для автоматизации процессов, связанных с
учетом потребления коммунальных ресурсов объектами Ленинградской области и
анализа эффективности потребления коммунальных ресурсов, а также передачи
накопленной информации во внешние системы.
2.1
Цель создания Подсистемы
Основными целями являются:
 оптимизация потребления коммунальных ресурсов;
 контроль работоспособности коммерческого оборудования учета
потребления коммунальных ресурсов;
 контроль потребления коммунальных ресурсов;
 выявление нарушений в части потребления, поставки и учета
потребления коммунальных ресурсов.
2.2
Назначение Подсистемы
Подсистема обеспечивает решение следующих задач при условии
получения и использования достоверной и актуальной информации:
 Сбор, хранение, обработка и передача сведений и данных от
потребителей коммунальных ресурсов Ленинградской области с целью
обеспечения возможности их анализа и использования в целях
повышения информационной открытости и качества управленческих
решений в регионе, а также их передачи во внешние системы (РГИС
«Энергоэффективность», Подсистема модуль «ТЭК ЛО», ФГИС
«АРШИН»);
 Организация в Ленинградской области источника данных о качестве
поставляемых коммунальных услуг для потребителей;
 Организация в Ленинградской области единого источника данных о
характеристиках учета коммунальных услуг;
13
 Организация в Ленинградской области получения объективных данных
о потреблении государственными и муниципальными учреждениями
Ленинградской области и населением (при наличии узла учета,
установленного на объекте и подключенного к информационной
Подсистеме) коммунальных ресурсов;
 Организация в Ленинградской области совершенствования механизма
расчета и повышения достоверности расчета необходимой валовой
выручки ресурсоснабжающих организаций и оптимизации процесса
выплаты субсидии РСО в связи с установлением льготных тарифов на
коммунальные
ресурсы
водоснабжения,
теплоснабжения
и
водоотведения, реализуемые населению на территории Ленинградской
области.
В Подсистеме предусмотрены сбор и хранение данных о поставляемых
коммунальных услугах учреждениям, для последующего получения объективных
данных о потреблении государственными и муниципальными учреждениями
Ленинградской области и населением (при наличии узла учета, установленного на
объекте и подключенного к информационной Подсистеме) коммунальных
ресурсов: теплоснабжения, водоснабжения и водоотведения, электроэнергии.
Получение таких данных производится путем установки передающих
устройств на государственных и муниципальных учреждениях, многоквартирных
жилых домах Ленинградской области, консолидации данных и передачи
консолидированных данных с настройкой шифрования по «ГОСТ Р 34.12-2015.
Национальный стандарт Российской Федерации. Информационная технология.
Криптографическая защита информации. Блочные шифры».
Основной задачей Исполнителя является развитие Подсистемы, в части
выполнения работ, для формирования отчетности и проведения аналитических
мероприятий, также настройка разграничения прав доступа, актуализация
справочников
и
отчетных
форм,
исправление
ошибок
и
актуализация
возможностей системы, синхронизация с государственными информационными
системами, обработка данных.
14
3
ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ
Объектом
развития
является
региональная
государственная
информационная Подсистема жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов Ленинградской области».
3.1
Основные сведения об объекте автоматизации
Компоненты
Подсистемы
обеспечивающему
раздельное
функциональных
приложений
построены
по
функционирование
и
модульному
и
принципу,
хранение
Web-ориентированных
данных
интерфейсов
пользователей.
В состав архитектуры РГИС ЖКХ ЛО входят следующие основные
серверные компоненты:
Рисунок 3.1 – Схема структурная Подсистемы
В Подсистеме осуществляется журналирование всех событий и действий
пользователей в Подсистеме. Журналы событий составлены в форме доступной для
проведения последующего анализа взаимодействия пользователей в Подсистеме,
15
модулей системы между собой и системы с внешними системами. Подсистема
взаимодействует с существующей инфраструктурой РГИС ЖКХ ЛО и другими
государственными информационными системами, в том числе в части единых
справочников.
Все
компоненты
Подсистемы
размещены
в
ЦОД
Правительства
Ленинградской области.
3.2
Состав Подсистемы
В состав Подсистемы входят следующие уровни обработки данных:
 Уровень источника данных, обеспечивающий фиксацию и сбор
событийной, визуальной и иной необходимой информации;
 Уровень средств вычислительной техники и средств информационного
обмена,
обеспечивающий
накопление
и
первичный
анализ
и
дальнейшую передачу информации, собранной на первом уровне
информации;
 Уровень программно-технических комплексов объектов мониторинга,
обеспечивающий
реструктуризацию
накопленной
и
проанализированной на втором уровне информации;
 Уровень
программно-технического
комплекса
центра
обработки
данных, обеспечивающий унифицированное представление событий на
объектах мониторинга для персонала, а также ретроспективный анализ
обработанной на третьем уровне информации.
Передача между разными уровнями событийной, визуальной и иной
требуемой для информирования персонала осуществляется средствами сетевого
взаимодействия.
В состав программно-технического комплекса центра обработки данных
входят следующие компоненты и программные службы:
 Сервер-коллектор первичной информации от инженерных систем:
 Подсистема сбора, консолидации и агрегации данных с первичного
инженерного оборудования;
16
 Подсистема
обогащения
событийной
информации
за
счет
инструментов расчета промежуточных показаний и агрегационных
функций;
 Сервер обеспечения работы бизнес-логики приложений:
 Подсистема сбора данных от инженерного оборудования;
 Подсистема ведения электронных паспортов объектов;
 Подсистема авторизации и аутентификации пользователей;
 Сервер визуализации, предоставляющий доступ к аналитической и
оперативной
информации,
формирующей
унифицированное
представление деятельности на контролируемых объектах в реальном
времени:
 Рабочее место главного диспетчера;
 Рабочее место диспетчера;
 Рабочее место главного инженера;
 Рабочее место ответственного за потребление коммунальных
ресурсов;
 Рабочее место мастера участка;
 Подсистема формирования отчетов;
 Мобильное
приложение
исполнителя
работ
и
оператора
диспетчерского центра;
 Оповещения о новых заявках;
 Контроль инженерного оборудования в обслуживаемых школах;
 Контроль аварийных ситуаций на инженерных системах.
Все
компоненты
Подсистемы
размещены
в
ЦОД
Правительства
Ленинградской области.
Используемое в составе Подсистемы программно-техническое обеспечение
представлено в таблице 3.1.
Таблица 3.1 – Программно-технические характеристики Подсистемы
№
п/п
Класс программного
обеспечения
Наименование
программного
обеспечения
Производитель
программного
обеспечения
17
Количество
Общее программное обеспечение
1
2
3
4
5
6
Операционные
РЕД ОС версия
ООО «РЕД СОФТ»
системы
7.3.
Открытая платформа .NET 8
Microsoft
для разработки
многоплатформенных
приложений
Подсистемы
PostgreSQL 14
ООО "ПОСТГРЕС
управления базами
ПРОФЕССИОНАЛЬНЫЙ"
данных
Специальное программное обеспечение
Платформа
dockerDocker, Inc
контейнеризации с
ce.x86_64.3:26.1.4открытым исходным 1.el7
кодом для
разработчиков и ИТспециалистов для
работы с кодами
Библиотека
jQuery v3.6.0
jQuery Board
JavaScript,
фокусирующаяся на
взаимодействии
JavaScript и HTML
Серверное и
Nginx angie-1.6.2- NGINX Inc
связующее ПО
1.el7.x86\_643
18
1
1
1
1
1
1
4
ТРЕБОВАНИЯ К АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЕ
4.1
Требования к структуре Подсистемы в целом
Функционалы,
которые
должны
поддерживаться
в
актуальном
и
работоспособном состоянии:
 Удаленный мониторинг объектов с помощью автоматизированного
рабочего места;
 Удаленный
мониторинг
ситуации
на
объектах
для
предотвращения/фиксации нештатных ситуаций;
 Передача оперативных данных о текущем состоянии систем и их вывод
на экраны Заказчика;
 Накопление, обработку и хранение информации, поступающей с
технических систем с обеспечением возможности анализа хранимой
информации, формирования отчетов;
 Формирование информационных сообщений с целью привлечения
внимания пользователей при возникновении нештатных ситуаций на
уровне прибора;
 Сбор и передачу данных со всех интегрированных систем в единое
хранилище данных с последующей обработкой по заранее заданным
алгоритмам;
 Сервер визуализации должен обеспечивать отображения оперативной
информации из систем объектов и параметров работы локальных систем
объектов;
 Визуальное отображение данных должно производиться в обобщенной
форме, в удобном и наглядном виде. События и инциденты должны
отображаться в оперативном режиме на карте города и планах объектов;
 Визуализация должна охватывать следующие уровни иерархии:
 Объекты мониторинга на интерактивной карте региона;
 Поэтажные схемы по каждому отдельному объекту.
 Сервер визуализации:
19
 Отображает данные об общем состоянии объекта мониторинга
на интерактивной карте региона;
 Отображает события/инциденты на схеме выбранного объекта;
 Просматривает
историю событий с возможностями их
фильтрации и группировки;
 Отображает динамику ключевых событий на графических
схемах с возможностями их фильтрации и группировки;
 Обеспечивает отображение информации в удобной и наглядной
форме на карте города и планах с детализацией необходимых
характеристик по отдельным объектам;
 Средства аналитики и построения отчетов обеспечивает:
 Хранение,
обмен
и
отображение
информации
в
унифицированном виде;
 Выгрузку основных данных в структурированном виде для
дальнейшей обработки вне Подсистемы;
 Построение отчетов в разрезе различных видов информации:
 Отчет о сбоях в работе технических средств;
 Отчет о внештатных ситуациях;
 Политика разграничения доступа и функциональности с учетом
заложенной ролевой модели;
 Администрирование объектов потребления - Право управления
объектами, адресами, договорами и привязками;
 Администрирование организации - Полный доступ к управлению
организацией;
 Администрирование системы - Полный доступ в систему без
ограничения прав доступа;
 Администрирование устройств - Право добавления и настройки
приборов учета;
 Аналитическая деятельность - Право настраивать уставки, право
доступа к ресурсонабжению и анализу энергоэффективности;
 Отчетная деятельность - Право формировать все виды отчетов;
20
 Просмотр объектов потребления - Право просмотра объектов,
адресов, договоров и привязок;
 Просмотр устройств - Право просмотра приборов учета;
 Экономическая деятельность - Право доступа к предбиллингу;
 В Подсистеме реализован механизм контроля доступа, обеспечивающий
аутентификацию пользователей при доступе ко всем компонентам
системы.
4.2
Требования к выполнению работ
Для выполнения работ надлежащего качества Исполнитель реализует
выполнение следующих мероприятий:
 Оптимизация производительности системы;
 Повышение качества и удобства пользовательских интерфейсов в
Подсистеме;
 Обеспечение
совместимости
новой
версии
Подсистемы
с
существующими модулями и инфраструктурой Заказчика;
 Обеспечение информационной безопасности, включая защиту
каналов связи, данных Пользователей и ведение журналов действий
в Подсистеме;
 Ведение и актуализация технической документации по Подсистеме,
включая документацию по обновлениям, архитектуре и интерфейсам
взаимодействия;
 Обеспечение процедуры управления изменениями с предварительным
согласованием, тестированием и фиксацией всех изменений в системе;
 Регулярное резервное копирование и проверка восстановления данных;
 Тестирование новых функций перед вводом в эксплуатацию;
 Проведение обучения пользователей и консультаций по возникающим
вопросам;
 Разработка и согласование с Заказчиком стратегического плана развития
Подсистемы на основе текущих потребностей и будущих тенденций.
21
5
ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ
5.1
Требования к математическому обеспечению Подсистемы
Дополнительные требования к математическому обеспечению Подсистемы
не предъявляются.
5.1.1
Требования к составу, структуре и способам организации данных
Состав, структура и способы организации данных и метаданных в
Подсистеме должны учитывать особенности предметной области. В состав
информационного обеспечения Подсистемы должны входить:
 оперативные данные – структурированная информация, которая должна
быть размещена в базе данных Подсистемы;
 электронные образы документов – неструктурированная информация,
которая должна быть размещена в файловом хранилище данных;
 служебная информация – структурированная информация, касающаяся
функционирования Подсистемы и размещаемая в служебных БД;
 нормативно-справочная информация (НСИ) – структурированная
условно-постоянная информация, размещенная в БД Подсистемы;
 внешние информационные ресурсы – структурированная информация,
принимаемая
от
других
автоматизированных
систем
(согласно
соглашениям об информационном обмене и техническим условиям
обмена) и размещаемая в БД Подсистемы;
 метаданные – структурированная информация об информационном
обеспечении Подсистемы, размещенная в служебных БД;
 формы
и
форматы
представления
выходных
документов
–
структурированная информация о содержании, оформлении и формате
представления выходных документов Подсистемы, размещенная в
служебных БД или файловом хранилище документов.
22
5.1.2
Требования к информационному обмену между компонентами
Подсистемы и со смежными ИСиС
Для тестирования информационного обмена Подсистемы со смежными
ИСиС должны использоваться тестовые площадки и тестовые учетные данные,
которые предоставляются Исполнителю Заказчиком работ.
Для обмена с внешними системами в приоритете должен быть использован
структурированный формат данных JSON. В случае, если формат JSON не
поддерживается смежной ИСиС, Исполнитель самостоятельно выбирает форматы
обмена и организует очереди обмена данными в соответствии с требованиями
смежной ИСиС.
В случае использования транспортных файлов, должны быть использованы
форматы XML, DBF, XLS и XLSX. Данные в файлах должны быть
структурированы и приведены к первой нормальной форме.
5.1.3
Требования к информационной совместимости со смежными ИСиС
Подсистема должна быть разработана с учетом принципов открытости и
поддерживать возможность взаимодействия по ключевым задачам через
программный интерфейс (API). Программный интерфейс должен быть построен в
соответствии с принципами RESTfull.
В случае изменений в структуре данных или форматах обмена, Подсистема
должна поддерживать управление версиями API, чтобы избежать конфликтов и
ошибок при синхронизации информации.
Инструментами Подсистемы, должна быть обеспечена возможность
мониторинга и аудита операций обмена данными со смежными ИСиС для
обеспечения прозрачности и контроля над процессами.
Запросы во внешние системы выполняются в соответствии с требованиями,
предъявляемыми в документации на внешние смежные и зашифрованы по
стандарту HTTPS over TLS.
При проектировании Подсистемы должны быть учтены актуальные
существующие решения по защите информации ИС, согласно требованиям
ФСТЭК,
с которыми
планируется
взаимодействие
23
Подсистемы,
а
также
реализованы механизмы взаимодействия с инфраструктурными сервисами
Заказчика в случае необходимости.
Способы взаимодействия со смежными ИС, а также получаемые из них
данные представлены в таблице №5.1.3-1
24
Таблица №5.1.3-1 – Информация о наличии и характере интеграционных взаимодействий Подсистемы с ИС
Наименование ИС
РГИС
«Энергоэффективност
ь ЛО»
Владелец: ГКУ ЛО
«ЦЭПЭ ЛО»
Подсистема (модуль)
«ТЭК ЛО».
Владелец: ГКУ ЛО
«ЦЭПЭ ЛО»
Место
расположения
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
Краткое описание ИС
Региональная
государственная
информационная
система по управлению
энергосбережением и
энергетической
эффективностью
региона,
энергосервисной
деятельностью, ведению
региональной
программы
энергосбережения
Подсистема
предназначена для
формирования
информационного
пространства топливноэнергетического
комплекса региона,
позволяющего
осуществлять
планирование развития
инженерноэнергетического
комплекса с учетом
территориальных
отраслевых схем
ресурсоснабжения и
Цель
информационного
взаимодействия
Виды
информации
Сбор необходимых
данных и
формирование
отчётности на уровне
муниципальных и
государственных
учреждений,
муниципалитетов,
региона в области
энергосбережения
Отчеты,
справочники,
Организации
Управление
региональным
топливноэнергетическим
хозяйством,
формирование
информационного
пространства
топливноэнергетического
комплекса региона,
позволяющее
осуществлять
планирование
развития инженерно-
Отчеты,
справочники,
графические
данные
25
Возможный способ
взаимодействия
Протокол
взаимодействия:
HTTPS
Формат
взаимодействия:
синхронный API на
базе JSON запросов
Протокол
взаимодействия:
HTTPS
Формат
взаимодействия:
синхронный API на
базе JSON запросов
Наименование ИС
Место
расположения
Краткое описание ИС
генерального плана,
согласование и контроль
за выполнением
инвестиционных
программ, расчета
наиболее эффективного
распределения
энергетических
мощностей
Сервер электронной
почты
Владелец: ГКУ ЛО
«ЦЭПЭ ЛО»
РГИС ЖКХ ЛО
Владелец: Комитет
цифрового развития
Ленинградской
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
Программное
обеспечение для работы
сервера электронной
почты, на который
осуществляется прием
обращений и отправка
уведомлений
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
Региональная
государственная
информационная
система жилищного
хозяйства
Цель
информационного
взаимодействия
энергетического
комплекса с учетом
территориальных
отраслевых схем
ресурсоснабжения и
генерального плана,
согласование и
контроль за
выполнением
инвестиционных
программ, расчета
наиболее
эффективного
распределения
энергетических
мощностей
Получение писем,
рассылка
уведомлений об
изменении состояния
обращений или
информационных
сообщений
Получение данных
по жилищному
фонду.
Виды
информации
Возможный способ
взаимодействия
Входящие письма
для
администраторов,
сотрудников,
обращения
пользователей,
уведомления о
событиях и
задачах
Данные паспортов
МКД
Протокол
взаимодействия:
 получение почты по
протоколам IMAP
или POP3
 отправка почты по
протоколу SMTP.
Протокол
взаимодействия:
HTTPS
Формат
26
Наименование ИС
Место
расположения
области
Краткое описание ИС
Цель
информационного
взаимодействия
Виды
информации
Ленинградской области
Государственный
адресный реестр (ГАР)
Москва,
Походный
проезд, дом 3,
строение 1
Предназначена для
автоматизации работы с
адресами и
обеспечивает их
актуальность и
единообразие
Получение
информации об
адресах
Федеральная
информационная
адресная система
(ФИАС)
Москва,
Походный
проезд, дом 3,
строение 1
Федеральная
государственная
информационная
система,
обеспечивающая
формирование, ведение
и использование
Государственного
адресного реестра
Получение
информации об
адресах
ФГИС «Аршин»
Москва,
Пресненская
наб. д. 10 стр. 2
Специализированная
онлайн платформа,
которая предназначена
для учета и хранения
сведений, касающихся
Получение данных о
сроках поверки
приборов учета
27
Информация о
земельных
участках и
объектах
капитального
строительства,
таких как дома,
квартиры,
владения,
строения и
сооружения
Информация о
земельных
участках и
объектах
капитального
строительства,
таких как дома,
квартиры,
владения,
строения и
сооружения
Название модели
прибора учета
Тип модели
Серийный номер
Ресурс
Возможный способ
взаимодействия
взаимодействия:
синхронный API на
базе JSON запросов
Открытые данные
(файловые
выгрузки/транспортные
файлы)
Открытые данные
(файловые
выгрузки/транспортные
файлы)
Открытые данные
(файловые
выгрузки/транспортные
файлы
Наименование ИС
Место
расположения
Краткое описание ИС
Цель
информационного
взаимодействия
результатов поверки
средств измерений,
включая приборы
коммерческого учета
Виды
информации
Условный
диаметр
Дата установки
Дата начала
поверки
Дата окончания
поверки
Номер документа
28
Возможный способ
взаимодействия
5.1.4
Требования по применению систем управления базами данных
Для контроля и хранения данных должна использоваться СУБД из реестра,
включенных в реестр российского ПО или допущенная к использованию
программными продуктами, включенными в реестр.
СУБД должна обеспечивать транзакционные механизмы, декларативную
ссылочную целостность, а также позволять наращивать производительность всего
комплекса путем увеличения мощностей технических средств без изменений на
прикладном уровне.
СУБД должна использоваться всеми модулями Подсистемы. Все данные,
кроме электронных образов документов, изображений и журналов событий
должны храниться в СУБД.
5.1.5
Требования к представлению данных в подсистеме
Дополнительные требования к представлению данных в Подсистеме не
предъявляются.
5.1.6
Требования к контролю, хранению, обновлению
и восстановлению данных
Для хранения файлов и иных бинарных данных должна использоваться
горизонтально масштабируемая система хранения данных, не ниже уровня
RAID10.
Для обеспечения возможности восстановления данных в случае их
ошибочного изменения и ведения журнала изменений данных в поставляемой
системе должен быть обеспечен механизм версионности данных.
В случае использования внешних по отношению к СУБД инструментов для
контроля, хранения и восстановления данных, должны использоваться решения с
открытым исходным кодом или импортозамещённые решения.
29
5.2
Требования к лингвистическому обеспечению Подсистемы
5.2.1
Требования к языкам, используемым в Подсистеме
Лингвистическое обеспечение Подсистемы должно быть рассчитано на
пользователя, специалиста в предметной области, не владеющего универсальными
языками программирования или описаниями алгоритмов.
Пользовательский интерфейс должен быть локализован для Российской
Федерации. Вся текстовая информация должна быть представлена на русском
языке.
Возможность расширения состава используемых языков – не требуется.
5.2.2
Требования к способам организации диалога
Взаимодействие пользователей с Подсистемой должно осуществляться
посредством
визуального
графического
интерфейса,
который
проходит
утверждение у заказчика в виде макета после его подготовки.
Все необратимые действия должны осуществляться с использованием
дополнительных диалогов подтверждения.
5.2.3
Требования к разработке и использованию словарей, тезаурусов
Не предъявляются.
5.2.4
Требования к описанию синтаксиса формализованного языка
Не предъявляются.
5.3
Требования к программному обеспечению Подсистемы
5.3.1
Требования к составу и видам программного обеспечения
Используемое при разработке программное обеспечение и библиотеки
программных
кодов
должны
иметь
широкое
распространение,
общедоступными и использоваться в промышленных масштабах.
30
быть
5.3.2
Требования к выбору используемого программного обеспечения
Используемое в составе Подсистемы программное обеспечение и языки
программирования должны подходить для последующей регистрации Подсистемы
в Реестре российского программного обеспечения.
Для
программного
обеспечения
клиентской
части
Подсистемы
предъявляются следующие требования:
 работа в операционных системах, включенных в Единый реестр
российских программ для электронных вычислительных машин и баз
данных;
 использование интернет-браузера, включенного в Единый реестр
российских программ для электронных вычислительных машин и баз
данных, совместимого с соответствующей операционной системой.
Для
программного
обеспечения
серверной
части
Подсистемы
предъявляются следующие требования:
 функционирование в серверных системах, включенных в Единый реестр
российских программ для электронных вычислительных машин и баз
данных;
 использование языков и библиотек, допустимых для использования в
программах, которые будут включены в Единый реестр российских
программ для электронных вычислительных машин и баз данных;
 функционирование на СУБД, включенной в Единый реестр российских
программ для электронных вычислительных машин и баз данных.
5.3.3
Требования к разрабатываемому программному обеспечению
Система должна быть рассчитана на использование браузеров с поддержкой
HTML 5.0, CSS Level 3, JQuery 3.6, режима асинхронного взаимодействия
JavaScript/XML (XML, HTTP, Request и т.п.).
Пользовательские
интерфейсы
должны
быть
протестированы
совместимость с браузером Яндекс.Браузер версии 24.6.3 и выше.
31
на
5.3.4
Требования к покупным программным средствам
В Подсистеме должны быть использованы только те сторонние
компоненты, которые могут быть приобретены (получены) и используются без
нарушений лицензионных соглашений, доступны к приобретению на территории
Российской Федерации, с учетом рекомендаций по импортозамещению.
5.4
Требования к техническому обеспечению
В разделе представлены общие требования к техническому и программному
обеспечению, на котором будет функционировать Подсистема.
Окончательный состав серверного и сетевого оборудования, систем
хранения данных определяется на этапе проектирования.
5.4.1
5.4.1.1
Требования к системно-технической инфраструктуре
Требования к локальным вычислительным сетям
Серверы БД, приложений, прикладного ПО и файловый сервер должны
быть объединены одной локальной сетью с пропускной способностью 1 Гбит/сек.
Пропускная способность канала передачи данных от Web-сервера и
файлового сервера до рабочих мест пользователей должна быть организована
защищенным каналом связи с пропускной способностью не менее 3 Мбит/сек на
пользователя.
Защита каналов связи должна обеспечиваться сертифицированными
средствами защиты.
5.4.1.2
Требования к вычислительным комплексам
Сервера должны быть размещены в дата-центре, обеспечивающем:
 несколько скоростных подключений к сети Интернет;
 круглосуточную гарантированную физическую защиту периметра от
доступа посторонних;
 наличие систем автономного кондиционирования;
 две независимые системы электропитания, включая резервные;
 наличие системы пожаротушения.
32
Для
размещения
Подсистемы
должны
использоваться
аппаратно-
программные средства с поддержкой работы виртуальных машин и механизмов
контейнеризации.
Для обеспечения стабильной работы аппаратной составляющей системы
должны быть предусмотрены инструменты для мониторинга и управления всеми
компонентами инфраструктуры, включая серверы, сети, хранилища данных и
приложения.
5.4.1.3
Требования к системам хранения данных
К системам хранения данных, на которых будет размещаться Подсистема
предъявляются следующие требования:
 система хранения построена на SSD или SSD M.2 уровня не ниже
RAID10;
 технические решения должны быть основаны на базе серийно
выпускаемых программных, аппаратных или программно-аппаратных
средств, срок технической поддержки которых заканчивается не ранее
чем через 3 года с момента ввода Подсистемы в эксплуатацию.
5.4.2
Требования к автоматизированным рабочим местам
В
качестве
пользовательского
оборудования
Заказчиком
должны
использоваться средства вычислительной техники, обеспечивающие работу
следующего программного обеспечения:
 операционной системы РЕД ОС 7.3 «Рабочая станция»;
 браузера Яндекс. Браузер версии 24.6.3 и выше.
5.4.3
Требования к функциональным группам серверов
Для
выполнения
показателей
надежности
и
отказоустойчивости
Подсистемы в технические требования к Подсистеме должны быть заложены узлы
для балансировки нагрузки и создания отказоустойчивых кластеров на уровне вебсервера и сервера баз данных.
33
5.5
Требования к метрологическому обеспечению
Дополнительные
требования
к
метрологическому
обеспечению
не
предъявляются.
5.6
Требования к организационному обеспечению
Для обеспечения качественной и непрерывной работы Подсистемы
Исполнитель должен руководствоваться требованиями к порядку организации
работы при сбоях и нештатных ситуациях.
5.6.1
Требования к порядку организации работы при сбоях и нештатных
ситуациях
При
возникновении
сбоев
или
нештатных
ситуаций
в
работе
информационной Подсистемы или ее инфраструктуры должна быть обеспечена
следующая последовательность действий сотрудников Заказчика с целью
минимизации последствий и времени простоя:
 Выявление проблемы:
 Пользователи или автоматические системы мониторинга сообщают
о проблеме;
 Служба поддержки фиксирует инцидент, классифицирует его по
приоритету и категории;
 При невозможности оперативного решения инцидента на текущем
уровне компетенции, инцидент должен быть передан на следующий
уровень технической поддержки или ответственному руководителю
для скорейшего решения инцидента;
 При более масштабных инцидентах разрабатывается специальный
план для более быстрого реагирования на инциденты;
 Все действия по инциденту должны фиксироваться с временными
метками: (кто, когда и что предпринял) – последующего анализа и
отчетности;
34
 По завершении инцидента(ов) проводится всесторонний анализ
целостности и работоспособности компонентов Подсистемы и её баз
данных
для
последующего
определения
ущерба,
причинённого
инцидентом(и). После выявления последствий разрабатываются и
реализуются меры по их устранению, а также по предотвращению
аналогичных ситуаций в будущем. При этом проводится оценка
остаточного риска, связанного с выявленными уязвимостями или
последствиями, и при необходимости принимаются компенсирующие
меры по его снижению до приемлемого уровня.
 Анализ и диагностика инцидента:
 Специалисты проводят анализ ситуации, чтобы определить причину
сбоя;
 При необходимости привлекаются разработчики, администраторы
систем или специалисты по безопасности;
 Производится
оценка
возможности
устранения
инцидента,
необходимые ресурсы и сроки выполнения работ.
 Устранение проблемы:
 Если проблема связана с оборудованием, принимаются меры по
восстановлению работоспособности оборудования, сервера или сети;
 В случае программного сбоя проводится перезапуск служб, изменение
настроек системы и прикладного ПО, в случае необходимости,
производится исправление кода Подсистемы;
 Для оперативного восстановления работоспособности Подсистемы
могут применяться временные обходные решения.
 Оценка последствий и восстановление после сбоев:
 После устранения проблемы оценивается влияние инцидента на бизнеспроцессы;
 Для критичных инцидентов принимаются меры по предотвращению
инцидентов в процессе дальнейшей эксплуатации;
35
 Проводится
проверка
корректности
восстановления
данных
и
обеспечению
не
функционирования Подсистемы.
5.7
Требования к методическому обеспечению
Дополнительные
требования
к
методическому
предъявляются.
36
6
ОБЩИЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ПОДСИСТЕМЕ
6.1
Требования к надежности Подсистемы
 Должно быть предусмотрено сохранение работоспособности Сервисов
(алгоритмов обеспечивающих функционирование бизнес-процессов
Подсистемы) при некорректных действиях пользователя и сохранение
целостности данных при нештатном завершении работы Сервиса (отказ
рабочей станции, потеря сетевого доступа и т.п.);
 В Подсистеме должен быть реализован контроль версий компонентов,
обеспечивающий возможность отката к предыдущим стабильным
версиям в случае сбоев после обновлений;
 Сервисы должны иметь средства обеспечения отказоустойчивости
(например, средства репликации и резервирование вычислительных
узлов);
 Сервисы должны предоставлять механизмы обеспечения сохранности
данных через применение процедур резервного копирования и
восстановления, описанных в документации Сервиса;
 Архитектура
Подсистемы
должна
соответствовать
требованиям
действующего законодательства РФ в области информационной
безопасности;
 Автоматическое восстановление сервисов при сбоях без вмешательства
пользователя;
 Проведение регулярных тестов на устойчивость к сбоям и проверок
корректности восстановления данных;
 Реализация журналирования критических событий с возможностью их
централизованного анализа;
 Реализация защиты от перегрузки, включая ограничение частоты
запросов и блокировку потенциально опасной активности;
 Обеспечение работы Подсистемы при кратковременном отсутствии
сетевого соединения за счет локального кэширования с последующей
синхронизацией данных;
37
 Ведение дублирующих логов и копий конфигурационных файлов в
защищенном хранилище;
 Исполнитель должен периодически проводить тестирование сценариев
отказа (в том числе моделирование отказа сетевого взаимодействия,
остановки узлов и пр.) с целью проверки работоспособности механизмов
отказоустойчивости и готовности к нештатным ситуациям;
 Все обновления Сервиса должны производиться с соблюдением
процедур
безопасного
развертывания
—
без
прерывания
предоставления услуг или с минимальными допустимыми перерывами,
заранее согласованными с Заказчиком.
6.2
Требования по конфиденциальности
Подсистема находится на серверах Заказчика. Исполнитель осуществляет
развитие Подсистемы в соответствии с действующими регламентами Заказчика.
Выполняемые работы должны удовлетворять требованиям качества и
безопасности в соответствии с действующим законодательством Российской
Федерации, Ленинградской области, а также удовлетворять техническим
требованиям, представленным в настоящем ООЗ (техническом задании).
Качество выполненных работ должно обеспечиваться в соответствии с
требованиями статьи 721 Гражданского кодекса Российской Федерации.
Работы должны быть оказаны в срок, в полном объеме и с надлежащим
качеством в соответствии с требованиями настоящего Описания объекта закупки и
государственного контракта.
Исполнитель не имеет права передавать третьим лицам информацию,
полученную в процессе выполнения работ, и сведения о характере выполняемых
работах, а также обеспечить конфиденциальность и безопасность этой информации
в соответствии с требованиями действующего законодательства Российской
Федерации.
38
Обработка и хранение информации ограниченного доступа должны
производиться
в
соответствии
с
действующим
законодательством
и
организационно-распорядительными документами Заказчика.
Работы не должны приводить к потере информации, ранее размещенной в
Подсистеме, или потере доступных ранее функциональных возможностей.
Исполнитель обязан выполнять работы с соблюдением действующих
правил и норм техники безопасности, пожарной безопасности, а также иных
утвержденных
и
зарегистрированных
в
установленном
порядке
актов
уполномоченных органов государственной власти в сфере охраны труда.
Защита Подсистемы от несанкционированного доступа обеспечивается:
 аутентификацией пользователей по паролю условно-постоянного
действия;
 функциями регистрации входа/выхода пользователя в/из системы и
попытки неудачного входа в систему (для блокирования попыток
подбора паролей);
 организацией доступа к данным и функциям Подсистемы на основании
разработанной ролевой модели Подсистемы;
 автоматическим завершением сеанса пользователя после определенного
периода бездействия;
 обеспечением безопасности при внедрении обновлений: обязательное
тестирование новых версий на предмет соответствия требованиям ИБ
Заказчика;
 проведением
регулярных
проверок
Подсистемы
на
наличие
уязвимостей.
Соблюдать методические рекомендаций по защите информации и контролю
действий пользователей, утверждённых ФСТЭК России.
6.3
Требования к эргономике и технической эстетике
При
отображении
числовых
данных
должны
быть
использованы
разделители разрядов. При отображении финансовой информации должно
39
использоваться выравнивание данных по правому краю блока и разделители
разрядов.
Все элементы управления, выполняющие одинаковые функции, называются
одинаково.
Поля, ввод информации в которые является обязательным, специально
отмечены для того, чтобы визуально отличаться от полей, заполнение которых
обязательным не является.
Подсистема предусматривает возможность использования справочников
при работе с полями ввода информации.
Допускается более долгое отображение экранных форм в разделах,
связанных с архивными данными.
При обнаружении Подсистемой ввода некорректных данных, информация в
корректно заполненных полях сохраняется, при этом пользователю предлагается
повторить ввод только данных, не прошедших проверку.
Дизайн интерфейса Подсистемы удовлетворяет следующим требованиям по
эргономике и технической эстетике:
 корректно
отображается
при
стандартных
разрешениях
экрана
(1920х1080 и выше) и количестве одновременно отображаемых цветов
монитора (от глубины цвета 16 bit);
 обладает системой контекстных подсказок на страницах, где у
пользователя потенциально могут возникнуть затруднения;
 адаптирован для восприятия интерфейса на различных браузерах
(кроссбраузерность);
 использовать единый стиль элементов управления, цветовой схемы,
типографии и пиктограмм во всей Подсистеме;
 гарантирует читаемость текста за счет достаточного контраста шрифта и
фона;
 содержит механизмы визуальной обратной связи (подсветка активных
элементов, на одной странице);
40
 поддерживается
единая
логика
навигации
по
Подсистеме,
обеспечивающая быстрое перемещение между основными разделами;
 предусмотрена защита от непреднамеренных действий пользователя
(подтверждение
при
удалении,
предупреждения
при
потере
несохраненных данных).
Требования к эргономике рабочих мест не предъявляются.
6.4
Требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов Подсистемы
Подсистема
рассчитана
на
эксплуатацию
в
составе
программно–
технического комплекса Заказчика и учитывать разделение ИТ инфраструктуры
Заказчика на внутреннюю и внешнюю.
Для эксплуатации Подсистемы должно быть обеспечено бесперебойное
питание серверов. При эксплуатации Подсистема должна быть обеспечена
соответствующая стандартам хранения носителей и эксплуатации температура и
влажность воздуха.
Периодическое техническое обслуживание используемых технических
средств должно проводиться в соответствии с требованиями технической
документации изготовителей, но не реже одного раза в год.
Эксплуатация технических средств Подсистемы должна производиться
специалистами Заказчика или уполномоченными подрядчиками с учетом
выполнения
требований
производителей
оборудования,
выполнением
периодического обслуживания и регламентных работ в рамках функционирования
службы эксплуатации ИС.
Обслуживание
технических
компонентов
Подсистемы
должно
производиться специализированным подразделением – службой эксплуатации ИС
или аналогичным, обладающим достаточной квалификацией.
Дополнительных требований к хранению компонентов Подсистемы не
предъявляется.
41
6.5
Требования к сохранности информации при авариях
Для
обеспечения
сохранности
информации
при
авариях
СУБД,
используемая в составе Подсистемы должна обеспечивать транзанкционность
записи данных для обеспечения их сохранности при авариях.
Перечень аварийных ситуаций, при которых должна быть обеспечена
сохранность информации:
 при сбоях в системе электроснабжения аппаратной части, приводящих к
перезагрузке ОС;
 при ошибках в работе аппаратных средств сервера приложений (кроме
носителей данных и программ);
 при сбоях сетевого оборудования и ошибках каналов связи между
сервером приложений и пользовательскими рабочими местами;
 при отказе сетевого оборудования;
 при сбоях в работе систем резервного копирования или восстановления
из резервной копии;
 при ошибках или некорректной работе программного обеспечения
серверной части Подсистемы (в том числе приложений, драйверов и
СУБД);
 при возникновении программных «зависаний» или утечек памяти в
процессе выполнения транзакций;
 при сбоях в работе OC сервера, включая критические ошибки ядра или
зависание системы;
 при ошибках или некорректных действиях администратора, ведущих к
незавершённым транзакциям или сбоям в логике работы;
 при сбоях в системах виртуализации или контейнеризации, если
Подсистема развёрнута в виртуальной среде;
 при ошибках при применении обновлений СУБД или миграции схемы
базы данных.
42
Для обеспечения непрерывного функционирования Подсистемы, в рамках
сопровождения,
организованы
мероприятия
по
резервированию
данных,
внесенных пользователями в Подсистему.
Для исключения потерь или порчи данных при отказе сетевого
оборудования должны использоваться транзакционные механизмы на уровне
СУБД.
6.6
Требования к защите от влияния внешних воздействий
Защита от влияния внешних воздействий должна обеспечиваться
средствами технического комплекса ЦОД Правительства Ленинградской области.
Для программных средств требования не предъявляются.
6.7
Требования к патентной чистоте и патентоспособности
Патентная чистота Подсистемы должна быть обеспечена в отношении
патентов,
действующих
на
территории
Российской
Федерации,
должны
соблюдаться положения законодательных актов Российской Федерации по
соблюдению авторских прав и защите специальных знаков.
Реализация технических, программных, организационных и иных решений
не должна приводить к нарушению авторских и смежных прав третьих лиц.
Исполнитель обязан обеспечить передачу Заказчику полученных по Контракту
результатов работ, не нарушающих исключительных прав других лиц и не
являющихся предметом залога, ареста или иного обременения.
В случае использования при выполнении работ по Контракту программ для
электронных
вычислительных
машин
(программных
комплексов
или
компонентов), разработанных третьими лицами, условия, на которых передаются
права на их использование (исполнение), должны обеспечить отсутствие
ограничений,
препятствующих
использованию
результатов
работ
по
их
назначению. При этом права, полученные Заказчиком, должны позволять ему
передавать, дорабатывать, развивать результаты работ, созданные в процессе
исполнения Контракта, а в случае явного указания в Техническом задании,
43
осуществлять переработку программ для электронных вычислительных машин
(программных комплексов или компонентов), разработанных ранее третьими
лицами в соответствии с требованиями законодательства Российской Федерации.
Исключительные права на результаты интеллектуальной деятельности, в
том числе, но не исключая: изобретения, полезные модели, промышленные
образцы, программы для электронных вычислительных машин, базы данных,
топологии интегральных микросхем, а также исключительные права на результаты
работ, включая объекты авторских прав и потенциально патентоспособные
технические решения, секреты производства (ноу-хау), созданные в рамках
Контракта, принадлежат субъекту Российской Федерации Ленинградской области,
от имени которого выступает Заказчик. Право собственности на результаты работ,
отчетные документы и материалы, полученные в ходе выполнения работ по
Контракту, принадлежат субъекту Российской Федерации Ленинградской области,
от имени которого выступает Заказчик и считаются переданными с момента
подписания Сторонами документа о приемке (технического акта) выполненных
работ.
В случае использования компонентов, распространяемых по открытым
лицензиям, Исполнитель обязан указать используемую лицензию и обеспечить,
чтобы её условия не препятствовали правомерному использованию, доработке и
распространению результатов работ.
Исключительные права на все результаты интеллектуальной деятельности,
созданные в рамках исполнения Контракта, включая объекты авторского права и
патентоспособные технические решения, полностью и безвозвратно передаются
Заказчику с момента подписания акта приёмки выполненных работ.
Исполнитель
несёт
полную
ответственность
за
правомерность
использования всех программных компонентов и технических решений,
применённых в рамках Контракта, включая обязательства по возмещению убытков
Заказчику в случае предъявления претензий со стороны третьих лиц.
44
7
СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ ПОДСИСТЕМЫ
7.1
Требования к безопасности выполнения работ
Информация, ставшая доступной сторонам в процессе выполнения работ по
Контракту, является информацией ограниченного доступа, в том числе к ней
относится:
 информация о Контракте и о результатах выполненных работ по нему;
 информация о технических и программных возможностях Сторон;
 информация о кредитно-финансовом положении Сторон;
 информация о документообороте Сторон;
 информация о методах и средствах защиты информации;
 информация о внутренних бизнес-процессах;
 исходные коды, скрипты, модули, используемые в процессе разработки;
 данные журналов регистрации событий, действий пользователей и
администраторов;
 информация о системах мониторинга, резервного копирования и
восстановления.
7.2
Требования к сроку и объему предоставления гарантий качества работ
Гарантийный срок на результаты выполненных Работ составляет 12
(двенадцать) месяцев от даты подписания Заказчиком документа о приемке в ЕИС по
последнему этапу исполнения Контракта.
Гарантийные
обязательства
Исполнителя
распространяются
на
все
программные и технические компоненты Подсистемы, включая интеграции с
внешними системами, разработанные или доработанные в рамках исполнения
Контракта.
В случае выявления ошибок, недостатков, а также отклонений от требований
настоящего технического задания, Исполнитель безвозмездно устраняет их в течение
гарантийного срока.
45
При повторном возникновении аналогичной ошибки в течение гарантийного
срока Исполнитель обязан провести комплексный анализ причин и реализовать
мероприятия по предотвращению подобных инцидентов в будущем.
Срок устранения выявленных в ходе эксплуатации ошибок и недостатков, а
также отклонений от требований настоящего технического задания, не более 10
(десяти) рабочих дней с момента получения сообщения от Заказчика о недостатках в
работе Подсистемы.
Устранение ошибок и недостатков должно сопровождаться предоставлением
Исполнителем отчета с указанием причин неисправности, предпринятых действий и
подтверждением восстановления работоспособности Подсистемы в полном объеме.
Гарантийный
срок
исчисляется
с
даты
подписания
акта
приёмки
соответствующего этапа работ, а при наличии замечаний — с момента подписания
акта об устранении всех выявленных недостатков.
7.3
Требования к объему работ
Техническая и эксплуатационная документация на Подсистему должны
удовлетворять требованиям комплекса стандартов и руководящих документов на
автоматизированные системы:
 ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Виды испытаний автоматизированных
систем»;
 ГОСТ Р 59853-2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Термины и
определения»;
 ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации.
Единая система конструкторской документации. Общие требования к
текстовым документам»;
46
 ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации.
Единая система конструкторской документации. Текстовые документы»;
 ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы. Виды,
комплектность
и
обозначение
документов
при
создании
автоматизированных систем»;
 ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы».
Подсистема должна удовлетворять ГОСТ Р 52872-2019 «Национальный
стандарт Российской Федерации. Интернет-ресурсы и другая информация,
представленная в электронно-цифровой форме. Приложения для стационарных и
мобильных устройств, иные пользовательские интерфейсы. Требования доступности
для людей с инвалидностью и других лиц с ограничениями жизнедеятельности».
47
8
ПОРЯДОК РАЗВИТИЯ АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЫ
8.1
Порядок развития Подсистемы
Состав и содержание работ по развитию функциональных возможностей
Подсистемы указаны в таблице 8.1.
Таблица №8.1 – Работы по развитию Подсистемы
№
п/п
Наименование работ
1.
Разработка функциональной
возможности выбора периода
графика и реестра в
функциональном модуле «Контроль
превышения фактического
теплопотребления от проектного»
раздела «Энергоэффективность»
2.
Разработка функциональной
возможности выбора периода в
модуле «Контроль температурного
графика» раздела
«Энергоэффективность»
3.
Разработка функции «печатная
форма» по разделу «Контроль
температурного графика» из дерева
объектов по выбранному ресурсу
«Теплоснабжение» выбранного
объекта в разделе
4.
Доработка модуля «Реестры» в
разделе формирования отчетности
«Сверхнормативное потребление
тепловой энергии», в части
доработки выбора района при
формировании отчета.
5.
Разработка экранной формы
«Контроль температурного
графика» по коммунальной услуге
Детализация
Реализовать отображение данных за период для
раздела График
Реализовать отображение данных за период для
раздела Карта
Реализовать отображение данных за период для
раздела Реестр
Реализовать печатную форму графика и реестра по
выбранному периоду
Итоговое тестирование
Реализовать отображение данных за период для
раздела График
Реализовать отображение данных за период для
раздела Карта
Создание раздела реестра с отображением
выбранного периода
Реализовать печатную форму отчета в разделе
реестр за выбранный период
Итоговое тестирование
Разработка печатной формы «Контроль
температурного графика» по объекту потребления
в разделе КТГ
Добавить возможность формировать отчет по
выбранному периоду «Контроль температурного
графика» из дерева объектов
Добавление в отчет функции нарушения и
отклонения подачи теплоносителя
Итоговое тестирование
В модуле «Реестры» в функции отчетности
«Сверхнормативное потребление тепловой
энергии» расширить возможности и функционал
возможностью выбора района
Запретить выбирать головной прибор, если не
указан объект головного прибора
Итоговое тестирование
Разработка механизмов подбора данных
(котельные, РСО, тип зданий)
Разработка экранной формы для отображения
48
№
Наименование работ
п/п
на уровне объекта потребления
6.
Добавление механизмов расчета
рекомендуемого расхода для
температурных графиков на уровне
объекта потребления, прибор
объекта
Детализация
информации о нарушениях температурного
графика в виде диаграммы или графика
Итоговое тестирование
Разработка функции расчета рекомендуемого
расхода для по температурному графику на
обратном трубопроводе в разделе КТГ прибора
объекта.
Разработка печатной формы для рекомендуемого
расчета по объекту.
Итоговое тестирование
7.
8.
9.
Разработка интерактивного виджета
на стартовой странице с
функциональной информацией по
перерасходу тепловой энергии от
нормативного показателя в
денежном выражении
Доработка формирования отчета в
модуле «Реестры», раздел
«Превышение лимитов
потребления» в части выбора района
без привязки к подключенным
объектам
Миграция (перенос) данных и
объектов схемы данных из текущей
СУБД PostgreSQL в целевую СУБД
Postgres Pro
Разработка механизма расчета
Обеспечено штатное функционирование виджета
на стартовой странице
Итоговое тестирование
Добавлено поле выбора района в разделе
формирования отчета по «Превышению лимитов
потребления»
Итоговое тестирование
Разработка плана миграции с определением
последовательности переноса объектов и оценкой
трудоемкости. Перенос и адаптация хранимых
процедур, функций, триггеров и других
программных объектов с учетом особенностей
Postgres Pro
Итоговое тестирование
8.2
Разработка функциональной возможности выбора периода графика и
реестра в функциональном модуле «Контроль превышения фактического
теплопотребления от проектного» раздела «Энергоэффективность»
Для обеспечения ретроспективного анализа данных системы в разрезе
объектов
и
функционала
периодов
«Контроль
требуется
реализовать
превышения
возможность
фактического
проектного» в разрезе периодов.
49
формирования
теплопотребления
от
Функционал может быть реализован путем добавления и переработки
существующей формы или путем добавления отдельного подраздела в разделе
«Энергоэффективность».
За
основу
функционала
должны
браться
данные
из
раздела
«Теплоснабжение», отображающего на уровне ресурса «Теплоснабжение» по
отдельному объекту.
Выбор адресов осуществляется в дереве объектов в левой части экранной
формы путем выбора уровня адресного плана: муниципальное образование, город,
улица, конкретный дом.
Выбор периода осуществляется при помощи специализированного поля ввода
дат. Ввод периода должен быть ограничен 6 месяцами в цели оптимизации времени
расчетов.
8.2.1
Реализовать отображение данных за период «с, по» для раздела
«График»
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «График», которой позволяет визуально сравнить между
отклонение в потреблении объектов от эталонных значений.
Для сравнения объектов должна быть реализована механика цветового
кодирования по выбранному периоду.
8.2.2
Реализовать отображение данных за период для раздела Карта
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «Карта», которой позволяет визуально выявить, где наибольшее
отклонение в потреблении объектов от эталонных значений.
Для сравнения объектов должна быть реализована механика цветового
кодирования и выбора периода.
8.2.3
Реализовать отображение данных за период для раздела Реестр
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «Реестр», которой позволяет сравнить между отклонение в
потреблении объектов от эталонных значений в числовом эквиваленте.
50
8.2.4
Реализовать печатную форму отчета
Для контроля результатов анализа требуется реализовать печатную форму с
собранной информацией по выбранному периоду и адресным объектам.
Предварительный состав информации:
 Дата и время формирования отчета;
 Период формирования отчетности;
 Пользователь, сформировавший отчет;
 Количество объектов, использованных для отчета;
 Табличная часть:
 Адрес объекта;
 Фактическое значение;
 Паспортное значение;
 Объем превышения паспортного значения в большую сторону (%);
 Объем превышения паспортного значения в большую сторону в
рублях.
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.3
Разработка функциональной возможности выбора периода в модуле
«Контроль температурного графика» раздела «Энергоэффективность»
Для обеспечения ретроспективного анализа данных системы в разрезе
объектов
и
периодов
требуется
реализовать
возможность
формирования
функционала «Контроль температурного графика» в разрезе периодов.
Функционал может быть реализован путем добавления и переработки
существующей формы или путем добавления отдельного подраздела в разделе
«Энергоэффективность».
За основу функционала должны браться данные, заведенного в систему
температурного графика и данные фактически поставленных на объект ресурсов.
51
Выбор адресов осуществляется в дереве объектов в левой части экранной
формы.
Выбор периода осуществляется при помощи специализированного поля ввода
дат. Ввод периода должен быть ограничен 6 месяцами в цели оптимизации времени
расчетов.
8.3.1
Реализовать отображение данных за период для раздела График
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «График», которой позволяет визуально сравнить между
отклонение в поставке ресурсов на объекты от эталонных значений температурного
графика по выбранному периоду.
График должен отображать цветом объекты, в которых количество дней с
отклонением превышает установленные в Системе значения.
Правила подбора внутри дня:
 Зеленое: отклонение в среднем за сутки до 3%;
 Желтое: отклонения в среднем за сутки выше 3%;
 Красная: отклонения в среднем за сутки выше 30% в отрицательную
сторону (дом остывает) при отрицательной температуре наружного
воздуха.
8.3.2
Реализовать отображение данных за период для раздела Карта
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «Карта», которой позволяет визуально выявить, где наибольшее
отклонение в температурных режимах от эталонных значений.
Для сравнения объектов должна быть реализована механика цветового
кодирования, описанная в правилах отображения графиков.
8.3.3
Реализовать отображение данных за период для раздела Реестр
Для визуального сравнения объектов между собой должен быть реализован
режим
просмотра
«Реестр»,
которой
позволяет
сравнить
количественные показатели отклонений от температурного графика.
52
между
собой
8.3.4
Реализовать печатную форму отчета
Для контроля результатов анализа требуется реализовать печатную форму с
собранной информацией по выбранному периоду и адресным объектам.
Предварительный состав информации:
 Дата и время формирования отчета;
 Пользователь, сформировавший отчет;
 Количество объектов, использованных для отчета;
 Табличная часть:
 Адрес объекта;
 Используемый график (название);
 Ресурсоснабжающая организация;
 Подача:

Среднее значение температуры на подаче;

Минимальное отклонение в натуральных показателях и %;

Дата минимального отклонения;

Температура наружного воздуха при минимуме;

Максимальное отклонение в натуральных показателях и %;

Дата максимального отклонения параметра;

Температура наружного воздуха при максимуме;
 Обратная труба:

Среднее значение температуры на обратной трубе;

Минимальное отклонение в натуральных показателях и %;

Дата минимального отклонения;

Температура наружного воздуха при минимуме;

Максимальное отклонение в натуральных показателях и %;

Дата максимального отклонения параметра;

Температура наружного воздуха при максимуме.
53
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.4
Разработка печатной формы «Контроль температурного графика» по
объекту потребления
Для передачи организациям, ответственным за обслуживание и эксплуатацию
объектов, а также организациям – поставщикам коммунальных ресурсов необходимо
реализовать
печатную
форму,
детализирующую
проблемы
с
соблюдением
температурного графика в разрезе конкретного объекта.
8.4.1
Реализовать возможность формировать отчет по конкретному объекту
Форма должна быть доступна из раздела «Отчеты» на уровне «Объект»
В печатной форме должно быть отображено:
 Входные параметры отчета: фильтры, даты, автор;
 Адрес объекта;
 Управляющая и владеющая организация;
 Ресурсоснабжающая организация;
 Наименование температурного графика;
 Вид контроля: по подаче / по обратному трубопроводу;
 Табличная часть:
 Дата фиксации;
 Температура наружного воздуха;
 Значение по температурному графику;
 Фактическое значение;
 Процент отклонения;
 Результирующая часть:
 Количество дней с отклонением до 3%;
 Количество дней с отклонением от 3% до 30%;
 Количество дней с отклонением более 30%.
54
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.4.2
Добавить возможность формировать отчет «Контроль температурного
графика» из дерева объектов
Необходимо
добавить
возможность
сформировать
отчет
«Контроль
температурного графика» с основной страницы «Дерево объектов» по объектам,
выбранным «галочкой» в адресном плане.
8.5
Доработка модуля «Реестры» в разделе формирования отчетности
«Сверхнормативное потребление тепловой энергии», в части доработки
выбора района при формировании отчета.
8.5.1
Добавить возможность выбора района
В модуле «Реестры» в функции отчетности «Сверхнормативное потребление
тепловой энергии» добавить возможность ограничить муниципальное образование
при формировании отчета.
Для пользователей с ролью «Система. Администратор» должны подбираться
все объекты в МО. Для прочих пользователей должны подбираться все объекты в МО,
к которым организация пользователя имеет доступ на основании привязок.
Одновременно может быть задан либо фильтр по муниципальному
образованию, либо по головному объекту (котельной).
Добавить фильтр по организации - поставщику коммунального ресурса.
Добавить фильтр по организации, отвечающей за эксплуатацию объекта:
подбирается по привязкам «Управление», «Владение», «Представление интересов
собственника».
Добавить фильтр по полю «Обслуживающая организация».
55
8.5.2
Запретить выбирать головной прибор, если не указан объект головного
прибора
Добавить обработку, которая будет блокировать выбор головного прибора,
если не указан головной объект.
8.6
Добавление
механизмов
расчета
рекомендуемого
расхода
для
температурных графиков
Для обеспечения контроля потребления и циркуляции внутри объекта
необходимо реализовать механизмы контроля и печатную форму, которая будет
отображать рекомендации по настройке циркуляции внутри объекта потребления.
Работа механизма контроля строится на основе температурного графика и
фактических значений потребления за период.
8.6.1
Разработка функции расчета рекомендуемого расхода для
температурного графика на обратном трубопроводе
Для
создания
возможности
контролировать
качество
циркуляции
теплоносителя внутри объектов и внесения корректировок в температурные графики
с целью оказания более качественных услуг, требуется изменить механизм
срабатывания уставки КЦ на уровне просмотра показаний прибора учета на обратной
трубе на следующую формулу:
М2рек=Qo*1000/(h(tгпрям;Рпрям)-h(tгобр;Робр))
Итоговое значение округляем в большую сторону до целого.
Изменить отображаемый текст уставки КЦ на следующий:
«Рекомендуемый расход получился меньше и его надо снизить до 52 т/ч.»
Новое уведомление должно выводиться в столбце «Предупреждение» во
вкладке «Архивные показания» на уровне «Прибор учета» вместо прежнего
сообщения.
8.6.2
Разработка печатной формы для рекомендуемого расхода по объекту
Разработать печатную форму, отображающую данные уставки КЦ и
рекомендации. Форма должна быть доступа с уровня.
56
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.7
Разработка
интерактивного
виджета
на
стартовой
странице
с
функциональной информацией по перерасходу тепловой энергии от
нормативного показателя в денежном выражении
На
стартовой
странице
системы
должен
быть
реализован
виджет
«Интегральный рейтинг энергоэффективности по тепловой энергии» в виде шкалы
(светофора), который отображает информацию об объеме перерасходуемой тепловой
энергии по всем объектам пользователя.
За основу расчета берется механизм расчета из раздела «Теплопотребление»
на уровне конкретного объекта.
Виджет доступен пользователям, привязанным к организациям, и отображает
информацию в разрезе конкретной организации.
Виджет должен корректно работать на объемах до 100 объектов у
пользователя. Загрузка виджета должна происходить асинхронно, т.е. не блокировать
загрузку остальных элементов на странице.
Виджет отображает информацию за последние сутки.
Первичной информацией для виджета является информация, отображаемая в
подразделе «Контроль превышения фактического теплопотребления от проектного»
раздела «Энергоэффективность».
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.8
Доработка
формирования
отчета
в
модуле
«Реестры»,
раздел
«Превышение лимитов потребления» в части выбора муниципального
образования без привязки к подключенным объектам
В форму заказа отчета «Превышение лимитов потребления» необходимо
добавить поле выбора муниципального образования в разделе формирования отчета.
57
Для пользователей с ролью «Система. Администратор», «ОГВ» и «ОМС»
должен быть доступен режим формирования отчета без учета привязки объектов к
организации пользователя. По умолчанию, для таких пользователей этот режим
должен быть включен.
Остальным пользователям, формирование отчета должно вестись по
доступным им объектам.
Для отчета должна быть реализована печатная форма, состав полей которой
подбирается Исполнителем на этапе технического проектирования.
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.9
О
замене
системы
управления
базами
данных
в
целях
импортозамещения и повышения уровня защиты информации
В рамках реализации стратегии технологического развития и обеспечения
независимости используемого программного стека принято решение о замене
системы управления базами данных PostgreSQL на отечественный продукт Postgres
Pro.
Данный
шаг
обусловлен
необходимостью
перехода
на
коммерчески
поддерживаемое решение с гарантированным уровнем сервисного обслуживания,
прогнозируемым жизненным циклом версий и расширенными средствами защиты
информации. Переход с PostgreSQL на Postgres Pro будет осуществлен в рамках
Контракта на развитие на 2026 год и позволит обеспечить бесперебойную и
безопасную эксплуатацию информационной системы в долгосрочной перспективе и
обеспечит завершение миграции без потери функциональности и с сохранением
штатной работы Подсистемы.
58
9
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ПОДСИСТЕМЫ
9.1
Виды испытаний и внедрение доработанной Подсистемы
Испытания проводятся с целью проверки соответствия доработанной
Подсистемы требованиям настоящего Технического задания.
До ввода доработанной Подсистемы в эксплуатацию обязательно провести
следующие виды испытаний в рамках выполнения работ по контракту:
 предварительные испытания;
 опытная эксплуатация;
 приемочные испытания.
Содержание
и
оформление
документов
«Программа
и
методика
предварительных испытаний», «Программа и методика опытной эксплуатации»,
«Программа и методика приемочных испытаний» должны учитывать требования
ГОСТ
Р
59792-2021
«Национальный
стандарт
Российской
Федерации.
Информационные технологии. Комплекс стандартов на автоматизированные
системы. Виды испытаний автоматизированных систем» и ГОСТ 19.301-79* (СТ СЭВ
3747-82) «Государственный стандарт Союза ССР. Единая система программной
документации. Программа и методика испытаний. Требования к содержанию и
оформлению».
Программа и методика испытаний разрабатывается Исполнителем в рамках
частного технического задания и предоставляется Заказчику не позднее даты
указанной в таблице 9.1, должна включать в себя необходимые для полноценной
проверки и испытаний тесты (контрольные примеры), которые обеспечивают полную
проверку функций и процедур по перечню, определенному в техническом задании.
59
Таблица 9.1 ПЛАН-ГРАФИК ПРОВЕДЕНИЯ ИСПЫТАНИЙ
Результат и подтверждающие
Этап испытаний
Длительность / Срок
Ответственный за проведение
Основные задачи и мероприятия
документы (согласно
Приложению 4)
1. Разработка и согласование с Заказчиком
программ и методик испытаний (для всех
этапов:
предварительных,
эксплуатации,
1. Подготовка к испытаниям
до 06.11.2026
Исполнитель
2.
опытной
приемочных).
Подготовка
тестовых
данных
и
• Программа
и
методика
предварительных
испытаний
• Программа и методика опытной
сценариев (контрольных примеров) для
эксплуатации
проверки всего функционала из Раздела 8
• Программа
ТЗ.
приемочных испытаний
и
методика
3. Развертывание доработанной версии
ПО на боевой системе.
1.
Проверка
новых
и
работоспособности
доработанных
всех
функций
из
Раздела 8 ТЗ (Контроль превышения
теплопотребления,
Контроль
температурного графика, новые виджеты,
печатные
2. Предварительные испытания
10 рабочих дней (06.11-
Исполнитель (с участием Заказчика
20.11.2026)
для фиксации результатов)
2.
формы
Проверка
взаимодействий
и
т.д.).
интеграционных
(API)
с
внешними
системами (РГИС Энергоэффективность,
ФГИС
Аршин
и
др.).
• Протокол
предварительных
испытаний.
• Решение
о
перехода
возможности
к
опытной
эксплуатации.
3. Проверка корректности установки и
настройки ПО на тестовом контуре.
4. Проверка документации на полноту и
соответствие.
3. Опытная эксплуатация (ОЭ)
1. Приказ Заказчика о начале ОЭ.
• Приказ
о
начале
ОЭ.
2. Работа пользователей в системе в
• Журнал опытной эксплуатации.
10 календарных дней (23.11-
Заказчик / Функциональный
реальном режиме. Выполнение реальных
• Протокол
02.12.2026)
заказчик (Пользователи)
бизнес-задач с использованием нового
эксплуатации (составляется по
функционала.
итогам,
3.
60
Исполнитель
осуществляет
выявленные
опытной
фиксируются
и
устраненные
Результат и подтверждающие
Этап испытаний
Длительность / Срок
Ответственный за проведение
Основные задачи и мероприятия
документы (согласно
Приложению 4)
техническую поддержку, консультирует
пользователей, оперативно исправляет
выявленные
критичные
ошибки.
4. Проверка корректности формирования
недостатки).
• Решение о возможности перехода
к приемочным испытаниям
отчетов, печатных форм.
1. Комплексная проверка системы в
полном объеме согласно утвержденной
"Программе и методике приемочных
испытаний".
2.
Демонстрация
Исполнителем
всех
функций ТЗ.
3.
Проверка
переданной
полноты
и
качества
документации,
исходных
кодов, инструкций по развертыванию.
4. Проверка способности системы к
восстановлению
5.
4. Приемочные испытания
8 рабочих дней (03.12 14.12.2026)
Приемочная комиссия (Заказчик,
Функциональный заказчик,
Исполнитель)
Анализ
после
сбоев.
результатов
опытной
эксплуатации.
6. Подписание членами комиссии Акта
приемочных
испытаний
(при
положительном результате).
7.
Подписание
Акта
сдачи-приемки
выполненных работ (Технического акта,
Приложение №1).
8. Передача всех исключительных прав
(подписание
Акта
приема-передачи
исключительных прав).
9.
Подписание
Акта
о
приемке
в
постоянную эксплуатацию.
10. Размещение документа о приемке в
ЕИС.
61
• Протокол
испытаний
приемочных
(с
итоговым
заключением).
• Акт приемочных испытаний.
• Акт о приемке в постоянную
эксплуатацию.
• Технический акт (приложение №1).
• Акт-приема
передачи
исключительных прав.
• Акт приемки-сдачи выполненных
работ.
• Размещение документа о приемке в
ЕИС.
9.2
Проведение профилактических работ
Проведение профилактических работ, влияющих на производительность
Подсистемы, допускается в нерабочее время и выходные дни по согласованию с
Заказчиком. Длительность профилактических работ в Подсистеме не должна
превышать 4 часов (за исключением ситуации физического выхода из строя
программно-технических средств). Срок выполнения запроса на оказание поддержки
пользователей,
связанной
с
расширением
и
изменением
функциональных
возможностей Подсистемы, должен зависеть от приоритета задачи. Исполнитель
должен оповестить пользователей Подсистемы о планируемых технических
мероприятиях.
9.3
Передача исходных кодов
Для вновь разрабатываемых и модернизируемых компонентов Подсистемы
Исполнитель должен передать Заказчику: скомпилированные и исходные коды,
дистрибутивы, для которых Исполнителем должна быть проведена проверка сборки
(компиляции) и последующего запуска с подтверждением функционирования
заявленных задач, а также инструкция проведения такой сборки (компиляции),
содержащая все необходимые для сборки и запуска компонентов Подсистемы
библиотек зависимостей, инструкций и программных сценариев (скриптов) для
проведения компиляции, создания дистрибутива и установки (развертывания)
компонентов Подсистемы, а также пароли от дистрибутивов, позволяющие
произвести открытие без повреждения данных. Исходные программные коды должны
содержать документирующие комментарии, описывающие назначение объекта
программы, смысл входных/выходных параметров для функции/процедуры, примеры
использования,
возможные
исключения,
особенности
реализации.
Документирующие комментарии должны быть оформлены как многострочные
комментарии перед документируемым элементом.
Дистрибутив
должен
иметь
средства,
подтверждающие
отсутствие
несанкционированных изменений. Подтверждение отсутствия фактов внесения
62
несанкционированных изменений в дистрибутив осуществляется посредством
сравнения контрольной суммы (ГОСТ Р 34.11-2012 «Национальный стандарт
Российской Федерации. Информационная технология. Криптографическая защита
информации.
Функция
хэширования»)
этого
дистрибутива,
указанной
в
документации на поставку.
Исходные коды должны быть организованы в логическую структуру с
соблюдением принятых стандартов кодирования, оформлены в виде репозитория с
понятной навигацией, что обеспечивает возможность их анализа, доработки и
сопровождения для Заказчика.
Вместе с исходными кодами должны быть переданы файлы конфигурации
и/или скрипты автоматизированной сборки (например, Makefile, Dockerfile, CI/CD
т.д.),
обеспечивающие
воспроизводимость
и
воспроизводимую
сборку
на
изолированной среде.
При наличии в составе исходных кодов сторонних библиотек и модулей,
поставляемых по открытым лицензиям, Исполнитель обязан предоставить перечень
таких компонентов с указанием лицензий, под которыми они распространяются, а
также
подтвердить
соответствие
условий
их
использования
требованиям
законодательства РФ и условиям Контракта.
Исполнитель несёт ответственность за полноту передаваемых исходных
материалов, их актуальность и соответствие финальной версии функционирующей
системы, в том числе за возможность их сборки и запуска без дополнительных
неофициальных зависимостей и скрытых настроек.
9.4
Общие требования к приемке работ
Приемка результатов работ осуществляется в соответствии с разделом 7
настоящего Технического задания.
По завершении работ Исполнитель предоставляет Заказчику результаты
работ. По завершении работ Исполнитель письменно уведомляет Заказчика о
готовности к сдаче работ и предоставляет Заказчику отчетные документы по
выполненным работам с сопроводительным письмом. Не позднее 2 (Двух) рабочих
63
дней, следующих за днем окончания выполнения работ, Исполнитель размещает в
единой информационной системе (ЕИС) документ о приемке.
При приемке результатов работ по каждому этапу работ, в которых
требовалось дорабатывать ПО, Исполнитель выполняет инсталляцию программного
обеспечения на оборудовании Заказчика, выполняет проверку работоспособности и
соблюдения функциональных требований настоящего Технического задания.
Исполнитель
разворачивает
и
настраивает
программное
обеспечение
Подсистемы в центре обработки данных Правительства Ленинградской области.
Испытания Подсистемы проводиться на АРМ Исполнителя/Функционального
заказчика согласно письменному уведомлению Заказчика о месте, дате и времени
проведения
испытаний.
Исполнитель
устанавливает
и
настраивает
общее/специальное программное обеспечение в ЦОД ЛО и на демонстрационном
автоматизированном рабочем месте. Заказчик письменно уведомляет Исполнителя о
месте и времени проведения приемки выполненных работ.
Приемка результатов выполненных работ проводится комиссией, в течение 20
(двадцати) рабочих дней с момента предоставления всех результатов работ по этапу.
Состав комиссии утверждается Заказчиком.
Председателем комиссии назначается представитель Заказчика. Со стороны
Функционального заказчика назначаются ответственные лица для включения в состав
приемочной комиссии по запросу Заказчика.
Исполнитель предоставляет комплект отчетных документов по результатам
выполненных
работ
и
проводимых
испытаний.
Результаты
выполненных
работ/испытаний должны быть зафиксированы в протоколах и актах. Протоколы и
акты подписываются всеми членами комиссии.
При положительном результате приемки выполненных работ у Исполнителя
подписывается протокол и акт всеми членами комиссии.
При отрицательном результате приемки выполненных работ у Исполнителя
подписываются протокол и акт всеми членами комиссии с фиксацией недостатков и
ошибок в реализации программного обеспечения, выявленных в ходе проведения
испытаний (предварительных испытаний; приемочных испытаний) и назначается
64
дата повторной приемки выполненных работ. Недостатки и замечания, указанные в
протоколе, должны быть устранены Исполнителем в согласованный с Заказчиком
срок.
В случае отсутствия замечаний к представленной Подсистеме, Заказчик
подписывает документ о приемке выполненных работ.
Недостатки и ошибки в реализации программного обеспечения Подсистемы,
выявленные в ходе приемки, должны быть устранены Исполнителем в рамках
выполнения Контракта, если только Сторонами не согласовано, что, исходя из
характера недостатков, они могут устраняться в рамках гарантийных обязательств
Исполнителя. Сроки и формат устранения замечаний и реализации рекомендаций,
данных комиссией в ходе испытаний, определяются в соответствующих протоколах.
Оформляются как недостатки реализации работ, исключительно выявленные как
отклонения от настоящего Технического задания, прочие недостатки могут
документироваться как желательные доработки.
Приемка работ по этапу, включающему доработку или разработку
программного обеспечения, осуществляется только при наличии переданных
Заказчику исходных кодов, а также актуальной технической и пользовательской
документации. Документация должна быть предоставлена в электронном и бумажном
виде, пригодном для последующего сопровождения.
9.5
Требования информационной безопасности при проведении работ по
развитию информационной системы
9.5.1 Требования информационной безопасности
Исполнитель выполняет мероприятия по информационной безопасности на
объектах
информатизации,
взаимодействующих
с
государственными
информационными системами Ленинградской области (далее - ГИС ЛО), в рамках
государственного контракта (далее - ГК), в соответствии с требованиями
федерального законодательства, законодательства Ленинградской области по
информационной
безопасности,
организационными
документами по информационной безопасности ГИС ЛО.
65
и
распорядительными
Доступ Исполнителя к ГИС ЛО осуществляется при наличии аттестатов
соответствия объектов информатизации требованиям информационной безопасности
не ниже требований, предъявляемым к ГИС ЛО.
Не допускается копирование Исполнителем информации, к которой им
предоставлен доступ, если такое копирование не предусмотрено в документах ГИС
ЛО, на основании которых Исполнителю предоставлен доступ к информационным
системам.
Исполнитель обязан исключить возможность несанкционированного доступа
или воздействий на ГИС ЛО и содержащуюся в ней информацию через
взаимодействующие с ГИС ЛО программно-аппаратные средства Исполнителя или
каналы передачи данных и интерфейсы, используемые Исполнителем для доступа
к информационным системам.
9.5.2 Требования к наличию лицензий
Исполнитель должен иметь действующие лицензии:
9.5.1.1 Лицензия ФСБ России на право осуществлять деятельность по
разработке, производству, распространению шифровальных (криптографических)
средств, информационных систем и телекоммуникационных систем, защищенных с
использованием шифровальных (криптографических) средств, выполнение работ,
оказание услуг в области шифрования информации, техническому обслуживанию
шифровальных
(криптографических)
средств,
информационных
систем
и
телекоммуникационных систем, защищенных с использованием шифровальных
(криптографических)
средств
(за
исключением
случая,
если
техническое
обслуживание шифровальных (криптографических) средств, информационных
систем
и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных (криптографических) средств, осуществляется для обеспечения
собственных нужд юридического лица или индивидуального предпринимателя) в
части работ, предусмотренных пунктами 2, 12 Перечня выполняемых работ и
оказываемых услуг, составляющих лицензируемую деятельность, в отношении
шифровальных (криптографических) средств, утвержденному постановлением
Правительства Российской Федерации от 16.04.2012 № 313 «Об утверждении
66
Положения
о
лицензировании
деятельности
по
разработке,
производству,
распространению шифровальных (криптографических) средств, информационных
систем
и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных (криптографических) средств, выполнению работ, оказанию услуг в
области шифрования информации, техническому обслуживанию шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств
(за
исключением
случая,
если
техническое
обслуживание
шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств,
осуществляется для обеспечения собственных нужд юридического лица или
индивидуального предпринимателя)», а именно «разработка защищенных с
использованием шифровальных (криптографических) средств информационных
систем»,
«монтаж,
установка
(инсталляция),
наладка
шифровальных
(криптографических) средств, за исключением шифровальных (криптографических)
средств защиты фискальных данных, разработанных для применения в составе
контрольно-кассовой
техники,
сертифицированных
Федеральной
службой
безопасности Российской Федерации, и шифровальных (криптографических)
средств, разработанных для применения в составе технологии, реализуемой
промежуточными элементами интеллектуальной системы учета электрической
энергии (мощности) и приборами учета электрической энергии, сертифицированных
Федеральной службой безопасности Российской Федерации».
Требование установлено на основании подпункта 1 пункта 1 статьи 12
Федерального закона от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов
деятельности», а именно «разработка, производство, распространение шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств,
выполнение работ, оказание услуг в области шифрования информации, техническое
обслуживание шифровальных (криптографических) средств, информационных
систем
и
телекоммуникационных
систем,
67
защищенных
с
использованием
шифровальных (криптографических) средств (за исключением случая, если
техническое
обслуживание
шифровальных
(криптографических)
средств,
информационных систем и телекоммуникационных систем, защищенных с
использованием шифровальных (криптографических) средств, осуществляется для
обеспечения
собственных
нужд
юридического
лица
или
индивидуального
предпринимателя)».
В случае отсутствия у Исполнителя действующей лицензии возможно
привлечение Соисполнителя.
9.5.1.2 Лицензия ФСТЭК России на право осуществления деятельности
по технической защите конфиденциальной информации в части работ,
предусмотренных подпунктом «д» и «е» пункта 4 Положения о лицензировании
деятельности
по
технической
защите
конфиденциальной
информации,
утвержденного постановлением Правительства Российской Федерации от 03.02.2012
№ 79 «О лицензировании деятельности по технической защите конфиденциальной
информации», а именно «работы и услуги по проектированию в защищенном
исполнении средств и систем информатизации» и «услуги по установке, монтажу,
наладке, испытаниям, ремонту средств защиты информации (программных
(программно-технических) средств защиты информации)».
Требование установлено в соответствии с подпунктом 5 пункта 1 статьи
12 Федерального закона от 04.05.2011 № 99-ФЗ «О лицензировании отдельных
видов
деятельности»,
а
именно
«деятельность
по
технической
защите
конфиденциальной информации».
Наличие п. 9.5.1.2 указанной лицензии обусловлено требованиями пунктами
5. «Требования к моделированию угроз безопасности информации», 4. «Требования к
разработке организационных, организационно-технических и распорядительных
документов по информационной безопасности при выполнении работ по развитию
ГИС ЛО, обрабатывающих информацию ограниченного доступа (далее - ПДн)».
В случае отсутствия у Исполнителя действующей лицензии возможно
привлечение Соисполнителя.
68
9.5.3 Требования к удаленному доступу
При необходимости удаленного доступа для Исполнителя такой доступ
предоставляется в соответствии с Областным Законом Ленинградской области № 60оз от 18.07.2016 «О государственных информационных системах Ленинградской
области» и постановлением Правительства Ленинградской области от 19 июня 2017
года № 229 «О правилах присоединения к единой сети передачи данных
Ленинградской области и правилах ее использования». При предоставлении
удаленного доступа Исполнитель осуществляет мероприятия по информационной
безопасности
на
объектах
информатизации
со
стороны
Исполнителя,
взаимодействующих с ГИС ЛО, в соответствии с требованиями федерального
законодательства и законодательства Ленинградской области по информационной
безопасности,
организационными
и
распорядительными
документами
по
информационной безопасности ГИС ЛО.
Удаленный доступ Исполнителя к Системе:
9.5.3.1 Не позднее 5 рабочих дней, следующего за днем заключения
Государственного контракта Исполнитель:
9.5.3.2 подает заявку Заказчику на присоединение к единой сети передачи
данных Ленинградской области (далее - ЕСПД);
9.5.3.3 подает заявку Заказчику на разграничение доступа к государственным
информационным ресурсам и системам Ленинградской области для субъектов, не
являющихся органом исполнительной власти Ленинградской области (при наличии
программного обеспечения защиты информации для защищённой сети ViPNet 6440);
9.5.3.4 В случае получения Заказчиком заявки в соответствии с п. 9.5.3.2
программное обеспечение защиты информации для защищённой сети ViPNet 6440
передается Исполнителю по Акту приема-передачи во временное пользование
на срок не более 60 календарных дней с целью возможности исполнения
Контракта до приобретения Исполнителем программного обеспечения (далее - ПО)
ViPNet за счет собственных средств;
9.5.3.5 В случае получения заявки, указанной в п. 9.5.3.3, Заказчик в срок не
позднее 5 (пяти) рабочих дней предоставляет соответствующий доступ;
69
9.5.3.6 Формы заявок, указанных в п. 9.5.3.2 и дополнительная информация о
присоединении к ЕСПД указана на сайте государственного казенного учреждения
Ленинградской области «Оператор «электронного правительства» (далее - ГКУ ЛО
«ОЭП») по адресу https://egov.lenreg.ru/?page_id=1276;
9.5.3.7 Исполнитель
обязан
исключить
возможность
использования
предоставленного удаленного доступа третьими лицами.
9.5.4. Требования к разработке организационных, организационно –
технических и распорядительных документов по информационной безопасности
при осуществлении развития ГИС ЛО.
9.5.4.1 Исполнитель разрабатывает (актуализирует) документ «Меры защиты
информации в ГИС ЛО в соответствии с требованиями и рекомендациями
федерального органа исполнительной власти в области обеспечения безопасности и
федерального
органа
исполнительной
власти,
уполномоченного
в
области
противодействия техническим разведкам и технической защиты информации.
Документ «Меры защиты информации в ГИС ЛО» должен содержать:
Перечень
организационных
и
технических
мер
по
обеспечению
информационной безопасности системы при ее эксплуатации;
Перечень
организационно-распорядительных
документов
по
информационной безопасности, разработка которых необходима в соответствии с
требованиями законодательства Российской Федерации, с указанием конкретных
пунктов и наименований нормативных, правовых, регулирующих, методических
документов, содержащих требования;
Перечень необходимых средств защиты информации, необходимых для
использования в ГИС ЛО, в том числе на автоматизированном рабочем месте,
серверном и коммутационном оборудовании.
Документ «Меры защиты информации в ГИС ЛО» согласуется с Заказчиком и
отделом
информационной
безопасности
Ленинградской области.
70
Комитета
цифрового
развития
9.5.4.2. Исполнитель актуализирует (разрабатывает при необходимости)
проекты: Акт классификации информационной системы, Акт определения уровня
защищенности ПДн при их обработке в информационной системе ПДн.
Форма
Акта
классификации
информационной
системы
должна
соответствовать приложению 3 к приказу ФСТЭК России от 29 апреля 2021 г. № 77.
Проекты актов согласуются с Заказчиком и отделом информационной
безопасности Комитета цифрового развития Ленинградской области.
9.5.4.3 Исполнитель актуализирует (разрабатывает при необходимости)
организационно-распорядительные и эксплуатационные документы, в частности:
–
технический паспорт ГИС ЛО;
–
журналы по защите информации;
–
матрицу доступа ГИС ЛО;
–
инструкции пользователя и администратора ГИС ЛО;
–
иные документы, указанные в документе «Меры по защите информации
в ГИС ЛО». Организационно-распорядительные документы не должны быть
типовыми и должны содержать актуальные сведения о ГИС ЛО.
9.5.5 Требования к моделированию угроз безопасности
С учетом целей развития и назначения Системы, предусматривается обработка
информации
ограниченного
доступа
(персональных
данных),
а
также
технологической информации, в том числе служебной информации о работе системы
защиты информации, и общедоступной информации.
Исполнитель проводит работы по актуализации (разработке) модели угроз
безопасности
информации
Системы,
в
соответствии
с
требованиями
и
рекомендациями федерального органа исполнительной власти в области обеспечения
безопасности и федерального органа исполнительной власти, уполномоченного в
области
противодействия
техническим
разведкам
и
технической
защиты
информации.
Структура и содержание Модели угроз безопасности информации Системы
должна соответствовать приведенной в Приложении № 3 к методическому документу
71
«Методика оценки угроз безопасности информации», утвержденному ФСТЭК России
05.02.2021.
Модель
угроз
должна
учитывать
совокупность
предположений
о
возможностях, которые могут использоваться при создании способов, подготовке и
проведении атак с целью нарушения безопасности, защищаемых средствами
криптографической защиты информации (далее - СКЗИ), персональных данных в
Системе в соответствии с требованиями приказа ФСБ России от 10.07.2014 № 378 «Об
утверждении Состава и содержания организационных и технических мер по
обеспечению
безопасности
персональных
данных
при
их
обработке
в
информационных системах персональных данных с использованием средств
криптографической
защиты
информации,
необходимых
для
выполнения
установленных Правительством Российской Федерации требований к защите
персональных данных для установленного уровня защищенности» и требованиями
документа «Методические рекомендации по разработке нормативных правовых
актов, определяющих угрозы безопасности персональных данных, актуальные при
обработке персональных данных в информационных системах персональных данных,
эксплуатируемых при осуществлении соответствующих видов деятельности»,
утвержденного 8 Центром ФСБ России 31.03.2015 №149/7/2/6-432.
По результатам моделирования угроз безопасности информации при развитии
ГИС Исполнитель представляет в Комитет цифрового развития Ленинградской
области актуализированную модель угроз и Заключение о необходимости проведения
дополнительных аттестационных испытаний или повторной аттестации, либо об
отсутствии необходимости проведения указанных мероприятий.
Комитет цифрового развития Ленинградской области по результатам
рассмотрения Заключения принимает решение о направлении модели угроз на
согласование в Федеральный орган исполнительной власти в области обеспечения
безопасности и Федеральный орган исполнительной власти, уполномоченный в
области противодействия техническим разведкам и технической защиты информации
(далее – Уполномоченные органы).
72
В случае получения замечаний от Уполномоченных органов Исполнитель
принимает меры к их устранению и повторно представляет модель угроз в Комитет
цифрового развития Ленинградской области для дальнейшего направления на
согласование в Уполномоченные органы.
9.5.5.1 Требования к выполнению работ по проведению аттестационных
испытаний/аттестации (при необходимости)
Аттестационные испытания/аттестация информационной системы (при
необходимости) организуется отделом информационной безопасности Комитета
цифрового развития Ленинградской области (далее – отдел ИБ КЦР) и включает
проведение
комплекса
организационных
и
технических
мероприятий
(аттестационных испытаний), в результате которых подтверждается соответствие
системы защиты информации информационной системы Требованиям о защите
информации,
не
составляющей
государственную
тайну,
содержащейся
в
государственных информационных системах.
Для проведения работ по аттестации Исполнитель предоставляет:
1.
Модель угроз;
2.
Перечень информации, обрабатываемой в ГИС ЛО, и подлежащей
защите (согласно приложению № 1);
3.
Технический паспорт ГИС ЛО;
4.
Меры защиты информации в ГИС ЛО;
5.
Журналы по защите информации;
6.
Матрицу доступа ГИС ЛО;
7.
Инструкции пользователя и администратора ГИС ЛО;
8.
Иные документы, указанные в документе «Меры по защите информации
в ГИС ЛО».
9.
Акт классификации ГИС ЛО;
10. Акт определения уровня защищенности.
73
9.5.6 Требования к устранению уязвимостей
9.5.6.1 В рамках выполнения работ Исполнитель обязан осуществить
устранение уязвимостей, выявленных на разрабатываемом функционале Системы, до
момента направления уведомления Заказчику о готовности к предварительным
испытаниям результатов.
9.5.6.2 Сканирование на наличие уязвимостей осуществляется Заказчиком:
При выполнении работ на СПО Системы: сканированию подлежит только
предоставленный Исполнителем исходный код;
При выполнении работ на ОПО (включая замену операционной системы,
СУБД и других системных компонентов): сканированию подлежит разрабатываемый
функционал Системы.
9.5.6.3 По результатам проведения сканирования Заказчик направляет
Исполнителю перечень выявленных уязвимостей через деловую почту ViPNet или
сообщает об их отсутствии.
В случае выявления уязвимостей Исполнитель составляет «Отчет
по результатам устранению уязвимостей» (далее - Отчет) содержащий:
–
перечень уязвимостей;
–
уровень опасности уязвимостей;
–
описание способа устранения уязвимостей;
–
дата устранения уязвимостей.
В
случае,
если
устранение
технологическими
и/или
организационными
Заказчика,
Исполнитель
направляет
уязвимости
невозможно
ограничениями
Заказчику
и
отделу
в
связи
с
инфраструктуры
информационной
безопасности Комитета цифрового развития Ленинградской области (далее – отдел
ИБ КЦР) в составе Отчета:
–
компенсирующие меры защиты;
–
альтернативные меры защиты;
–
обоснование невозможности устранения;
–
рекомендации по устранению уязвимостей.
74
Для подтверждения устранения уязвимостей выполняется контрольное
сканирование по дополнительному запросу Исполнителя, результаты прилагаются
к Отчёту.
Отчет предоставляется Заказчику не позднее чем за 14 календарных дней до
направления уведомления о готовности к предварительным испытаниям результатов.
9.5.6.4 Заказчик, отдел ИБ КЦР имеют право на внеплановое сканирование
Системы, по результатам которого Исполнитель выполняет мероприятия
в соответствии с п. 9.5.6.3.
9.5.6.5 Все выявленные в ходе действия ГК уязвимости безопасности на
разрабатываемом функционале Системы должны быть устранены Исполнителем.
При наличии уязвимостей, на разрабатываемом функционале Системы, которые не
были устранены в течение действия ГК, за исключением случаев, указанных в п.
9.5.6.3 Заказчик вправе признать ГК неисполненным.
9.5.6.6 Результатом анализа (мониторинга) уязвимостей Системы является
подтверждение отсутствия уязвимостей в Системе, содержащихся в банке данных
угроз
безопасности
информации
ФСТЭК
использования (эксплуатации) нарушителем.
75
России,
или
невозможности
их
10
ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ
ПО ПОДГОТОВКЕ ПОДСИСТЕМЫ К ВВОДУ В ДЕЙСТВИЕ
Результаты
оформляться
выполненных
Исполнителем
и
работ
по
развитию
предъявляться
Подсистемы
Заказчику
в
должны
соответствии
с
требованиями описания объекта закупки.
При этом все созданные в ходе выполнения работ результаты работ
принадлежат Заказчику.
Исполнитель не позднее даты окончания работ предоставляет Заказчику
отчетные документы согласно Приложению 4 настоящего ООЗ:
Все отчетные документы (журнал и отчеты) передаются Исполнителем
Заказчику в бумажном виде.
Акт
сдачи-приемки
выполненных
работ
направляется
Заказчику
в
соответствии с условиями заключенного контракта.
Исполнитель гарантирует корректность информации, содержащейся в
отчетных документах, и ее соответствие техническому состоянию Подсистемы, и
информации, содержащейся в Подсистеме - по состоянию на отчетную дату.
Установление факта несоответствия информации, содержащейся в отчетных
документах, техническому состоянию Подсистемы и информации, содержащейся в
Подсистеме, на отчетную дату является основанием для отказа от приемки
выполненных работ.
В случае обнаружения Заказчиком и документального подтверждения
недостоверных сведений в отчетных документах, Исполнитель обязан в течение 5
(пяти) рабочих дней с даты уведомления Заказчиком предоставить исправленные
документы. Повторное нарушение является основанием для направления претензии и
применения мер ответственности, предусмотренных контрактом.
Формы и структура отчетных документов, состав показателей, объем данных и
периодичность отчетности согласовываются Сторонами до начала выполнения работ
и оформляются приложением к Техническому заданию или Контракту.
76
11
ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
Документы, разрабатываемые в рамках настоящего ООЗ и относящиеся к
модифицированному
ПО
Подсистемы
должны
удовлетворять
требованиям
комплекса стандартов и руководящих документов на автоматизированные системы.
Все документы должны быть оформлены в едином стиле.
Порядок оформления и предъявления Заказчику результатов выполнения
работ в соответствии с рекомендациями следующих нормативных документов,
регламентирующим создание автоматизированных систем в сфере информационных
технологий:
 ГОСТ 34.201–2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы. Виды,
комплектность
и
обозначение
документов
при
создании
автоматизированных систем»;
 ГОСТ 34.602–2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы»;
 ГОСТ Р 59792–2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Виды испытаний автоматизированных
систем»;
 ГОСТ Р 59793–2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Стадии
создания».
Выходной
контроль
специализированным
документов
подразделением
на
Подсистему
Исполнителя
в
выполняется
соответствии
с
государственными стандартами и методическими указаниями. Описание и состав
разделов документации/документов может быть изменен Заказчиком в рабочем
порядке.
77
Заказчик вправе контролировать ход и качество оказанных работ, соблюдение
Исполнителем сроков их выполнения, получать информацию о промежуточных
результатах выполнения работ.
Оказываемые работы должны быть безопасны для жизни, здоровья людей,
имущества Заказчика и окружающей среды при обычных условиях их выполнения в
соответствии с Федеральным законом РФ от 30.03.1999 № 52-ФЗ «О санитарноэпидемиологическом благополучии населения».
78
12
ИСТОЧНИКИ РАЗРАБОТКИ
В качестве источников разработки технического задания использовались
следующие документы:
 Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об
информации, информационных технологиях и о защите информации».
 Методический документ ФСТЭК России «Методика оценки угроз
безопасности информации», утвержденная 05.02.2021.
 Приказ ФСТЭК России от 04.07.2022 № 118 «Об утверждении требований
по безопасности информации к средствам контейнеризации».
 ГОСТ 34.201-2020 – «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы. Виды,
комплектность
и
обозначение
документов
при
создании
автоматизированных систем»;
 ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Виды испытаний автоматизированных
систем»;
 ГОСТ Р 59793-2021 – «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Стадии
создания»;
 ГОСТ Р 59795-2021. «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Требования
к содержанию документов»;
 ГОСТ Р 59853-2021 – «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Термины и
определения»;
79
 ГОСТ 19.301-79* (СТ СЭВ 3747-82) «Государственный стандарт Союза
ССР. Единая система программной документации. Программа и методика
испытаний. Требования к содержанию и оформлению».

80
13
ПРИЛОЖЕНИЯ
Перечень приложений к настоящему Описанию объекта закупки:
 Приложение № 1 «Образец технического акта».
 Приложение № 2 «Сведения о местах выполнения работ».
 Приложение № 3 «Расчет стоимости выполнения работ».
 Приложение № 4 «Перечень отчетных документов, передаваемых
Заказчику».
 Приложение № 5 «Перечень информации, обрабатываемой в ГИС ЛО, и
подлежащей защите».
 Приложение № 6 «Обоснование невозможности соблюдения запрета по
предоставлению национального режима при осуществлении закупок
товаров, работ, услуг для обеспечения государственных нужд, закупок
товаров, работ, услуг отдельными видами юридических лиц».
81
Приложение № 1
к Описанию объекта закупки
ОБРАЗЕЦ
Технический акт
по государственному контракту № ___________ от ______________
на выполнение работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития Подсистемы «Учет
потребления коммунальных ресурсов Ленинградской области»
Санкт-Петербург
«____»_________ ____ г.
Приемочная комиссия, действующая на основании приказа государственного казенного
учреждения Ленинградской области «Центр энергосбережения и повышения энергоэффективности
Ленинградской области» (далее – ГКУ ЛО «ЦЭПЭ ЛО»)
от _______________________ № _________ (далее – Комиссия) составила настоящий акт о
нижеследующем:
1. Комиссия рассмотрела результаты выполнение работ по государственному контракту от
_________ № ___________________ за счет средств бюджета Ленинградской области на 202__ год,
государственная программа «_________», подпрограмма «_____________», основное мероприятие
«________», раздел/подраздел ____, КЦСР _______, КВР_____, КОСГУ ______, ДопКР _______
между ГКУ ЛО «ЦЭПЭ ЛО» (далее – Заказчик) и _________________________ (далее –
Исполнитель) на выполнение работ по развитию региональной государственной информационной
системы жилищно-коммунального хозяйства Ленинградской области в части развития Подсистемы
«Учет потребления коммунальных ресурсов Ленинградской области» (далее – Контракт), за
отчетный период с ______________ по __________________.
2.
2.1.
Комиссия установила:
Исполнитель за отчетный период с _____________ по ____________ выполнил работы:




По факту выполнение работ подлежит оплате ________________ (______________________), в том
числе НДС ____________________________.
2.2. Исполнитель по результатам выполненных работ представил Заказчику комплект отчетных
документов:



82
2.3. Объем, содержание и качество выполненных работ соответствуют требованиям Описания
объекта закупки. В ходе приёмки недостатков не выявлено.
2.4. Состав, комплектность и содержание отчетных документов, представленных Исполнителем,
соответствует требованиям Описания объекта закупки.
3. Комиссия решила:
3.1. Считать, что Исполнитель выполнил работы по Контракту за отчетный период с _____________
по ______________ в срок и в полном объеме в соответствии с требованиями Описания объекта
закупки.
3.2. Принять результаты выполненных работ по Контракту за отчетный период с ___________ по
_______________.
Акт составлен в двух экземплярах:
1 экземпляр – Заказчику – Государственное казенное учреждение Ленинградской области «Центр
энергосбережения и повышения энергоэффективности Ленинградской области»;
2 экземпляр – Исполнителю – _____________________.
Исполнитель:
От _____________:
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
Комиссия:
Заказчик:
от ГКУ ЛО «ЦЭПЭ ЛО»:
83
Приложение № 2
к описанию объекта закупки на выполнение работ по развитию Подсистемы региональной
государственной информационной системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов Ленинградской области»
Сведения о местах выполнения работ
№
п/п
Регион
1.
Санкт-Петербург
2.
Санкт-Петербург
3.
Санкт-Петербург
Адрес выполнение работ
Подсистема развернута на аппаратных мощностях ЦОД
Правительства Ленинградской области по адресу
Выборгское шоссе, д. 503, корп. 12
Государственное казенное учреждение Ленинградской
области «Центр энергосбережения и повышения
энергоэффективности Ленинградской области» СанктПетербург г., муниципальный округ Смольнинское
вн.тер.г., Калужский пер., дом 3, литера А
Комитет по топливно-энергетическому комплексу
Ленинградской области: г. Санкт-Петербург, ул.
Смольного, д. 3
84
Приложение № 3
к описанию объекта закупки на выполнение работ по развитию Подсистемы региональной
государственной информационной системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов Ленинградской области»
Расчет стоимости выполнения работ
№
Наименование услуг
1
1.1
1.2
1.3
1.4
1.5
1.6
Выполнение работ по развитию
региональной государственной
информационной системы
жилищно-коммунального
хозяйства Ленинградской области в
части развития Подсистемы «Учет
потребления коммунальных
ресурсов Ленинградской области»,
в том числе:
Разработка функциональной
возможности выбора периода
графика и реестра в функциональном
модуле «Контроль превышения
фактического теплопотребления от
проектного» раздела
«Энергоэффективность»
Разработка функциональной
возможности выбора периода в
модуле «Контроль температурного
графика» раздела
«Энергоэффективность»
Разработка функции «печатная
форма» по разделу «Контроль
температурного графика» из дерева
объектов по выбранному ресурсу
«Теплоснабжение» выбранного
объекта в разделе
Доработка модуля «Реестры» в
разделе формирования отчетности
«Сверхнормативное потребление
тепловой энергии», в части доработки
выбора района при формировании
отчета
Разработка экранной формы
«Контроль температурного графика»
по коммунальной услуге на уровне
объекта потребления
Добавление механизмов расчета
рекомендуемого расхода для
температурных графиков на уровне
объекта потребления, прибор объекта
Объем,
Ед.
измерения
Колво
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Цена за
ед. услуги без
НДС,
руб.
85
Цена за
ед.
услуги с
НДС,
руб.
Стоимос
ть услуг
без НДС,
руб.
Стоимос
ть услуг
с НДС,
руб.
1.7
1.8
1.9
Разработка интерактивного виджета
на стартовой странице с
функциональной информацией по
перерасходу тепловой энергии от
нормативного показателя в денежном
выражении
Доработка формирования отчета в
модуле «Реестры», раздел
«Превышение лимитов потребления»
в части выбора района без привязки к
подключенным объектам
Миграция (перенос) данных и
объектов схемы данных из текущей
СУБД PostgreSQL в целевую СУБД
Postgres Pro
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
86
Приложение № 4
к описанию объекта закупки на выполнение работ по развитию Подсистемы
региональной государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области «Учет потребления коммунальных ресурсов Ленинградской области»
Перечень отчетных документов, передаваемых Заказчику
№
п/п
1.
Наименование работ
Наименование отчетных документов
Работы по развитию Подсистемы
региональной государственной
информационной системы жилищнокоммунального хозяйства
Ленинградской области «Учет
потребления коммунальных ресурсов
Ленинградской области»
- акт приемочных испытаний;
- акт о приемке в опытную эксплуатацию;
- акты о приемке в постоянную эксплуатацию;
- акт приема-передачи исключительных прав;
- программа и методика предварительных
испытаний;
- программа и методика опытной эксплуатации;
- программа и методика приемочных испытаний;
- протокол приемочных испытаний;
- протокол опытной эксплуатации;
- протоколы тестирования (функционального,
нагрузочного, интеграционного) по требованию
Заказчика;
- схему структурного комплекса технических
средств (по требованию Заказчика);
- журнал опытной эксплуатации;
- целостные исходные коды, дистрибутивы
компиляторов, интерпретаторов и другого
программного обеспечения, библиотеки
зависимостей, плагины, инструкции и
программные сценарии (скрипты), инструкции по
развертыванию кодов (видео), базы данных;
- Технический акт передачи исходных кодов;
- Акт приемки-сдачи выполненных работ;
- Универсальный передаточный документ;
Приложение №5
к описанию объекта закупки на выполнение работ по развитию Подсистемы
региональной государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области «Учет потребления коммунальных ресурсов Ленинградской области»
87
ПЕРЕЧЕНЬ
информации, обрабатываемой в ГИС ЛО, и подлежащей защите
№
п/
п
Категория сведений
Основания
Наименование защищаемой
конфиденциального
отнесения к
информации
характера1
защищаемой
информации2
1
1.
Данные
приборами
об
оснащенности
учета
используемых
энергетических
государственных
Нет
(информация
ресурсов
и
относится к
муниципальных
публичной
учреждений
2
2.
информации)
Данные об объеме потребления
энергетических
государственных
Нет
Нет
Нет
ресурсов
и
(информация
муниципальных
относится к
публичной
информаци
учреждений
и
3
3.
Данные о поверках приборов
учета
энергетических
государственных
и
Нет
Нет
ресурсов
(информация
относится к
публичной
информаци
муниципальных
учреждений
и
4 Плановые и фактические значения
потребления энергетических ресурсов
4.
учреждений
государственных
и
Нет
Нет
(информация
относится
к
публичной
муниципальных образований
информации)
5
Плановые
и
фактические
Нет
Нет
В соответствии с Перечнем сведений конфиденциального характера, утвержденным Указом
Президента РФ от 6 марта 1997 г. N 188.
2
Номер пункта и реквизиты нормативного правового акта, устанавливающего соответствие
обрабатываемой информации категории сведений конфиденциального характера.
1
88
5.
значения
индикаторов
расчета
(информация
потреблений энергетических ресурсов
в
денежном
относится к
выражении
публичной
государственных и муниципальными
информации)
учреждениями
6
6.
Реестр
энергетических
Нет
договоров
(информация
(контрактов) заключенных в
относится к
публичной
инфо
течении года по государственным и
муниципальным учреждениям
7
7.
Сведения
Нет
о
рмации
снижении
Нет
потребления энергетических ресурсов
Нет
(информация
государственными и муниципальными
относится к
публичной
инфо
учреждениями
рмации
В соответствии с Перечнем сведений конфиденциального характера, утвержденным Указом
Президента РФ от 6 марта 1997 г. N 188.
2
Номер пункта и реквизиты нормативного правового акта, устанавливающего соответствие
обрабатываемой информации категории сведений конфиденциального характера.
89

=== ФАЙЛ: Приложение № 6 к Описанию объекта закупки.docx | docs/0145200000426001424/Приложение № 6 к Описанию объекта закупки.pdf
Приложение № 6
к описанию объекта закупки
ОБОСНОВАНИЕ НЕВОЗМОЖНОСТИ СОБЛЮДЕНИЯ ЗАПРЕТА ПО
ПРЕДОСТАВЛЕНИЮ НАЦИОНАЛЬНОГО РЕЖИМА ПРИ ОСУЩЕСТВЛЕНИИ
ЗАКУПОК ТОВАРОВ, РАБОТ, УСЛУГ ДЛЯ ОБЕСПЕЧЕНИЯ ГОСУДАРСТВЕННЫХ
НУЖД, ЗАКУПОК ТОВАРОВ, РАБОТ, УСЛУГ ОТДЕЛЬНЫМИ ВИДАМИ
ЮРИДИЧЕСКИХ ЛИЦ
В соответствии с частью 3 статьи 14 Федерального закона от 05.04.2013
№ 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для
обеспечения государственных и муниципальных нужд» и руководствуясь порядком,
утвержденным постановлением Правительства Российской Федерации от 23.12.2024
№ 1875 "О мерах по предоставлению национального режима при осуществлении
закупок товаров, работ, услуг для обеспечения государственных и муниципальных
нужд, закупок товаров, работ, услуг отдельными видами юридических лиц"(далее постановление Правительства Российской Федерации от 23.12.2024 № 1875),
Государственное казенное учреждение Ленинградской области «Центр
энергосбережения и повышения энергетической эффективности Ленинградской
области» представляет обоснование невозможности соблюдения запрета на допуск
программного обеспечения, происходящего из иностранных государств:
Заказчик: Государственное казенное учреждение Ленинградской области
«Центр энергосбережения и повышения энергетической эффективности
Ленинградской области».
Наименование объекта закупки: Выполнение работ по развитию региональной
государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области в части развития Подсистемы «Учет потребления
коммунальных ресурсов Ленинградской области».
Обстоятельство, обусловливающее невозможность соблюдения запрета:
Подпункт «ж» пункта 5 Постановления Правительства Российской Федерации от
23.12.2024 № 1875 подготовки обоснования неприменения запрета на допуск
программного обеспечения, происходящего из иностранных государств, для целей
осуществления закупок для обеспечения государственных и муниципальных нужд,
утвержденного Постановлением Правительства Российской Федерации от 23.12.2025
г. № 1875, а именно: при осуществлении закупки программного обеспечения,
указанного в позиции 146 приложения N 1 к настоящему постановлению,
программное обеспечение, сведения о котором по состоянию на день,
предшествующий дню размещения в единой информационной системе извещения об
осуществлении закупки, направления приглашения принять участие в определении
поставщика (подрядчика, исполнителя), заключения контракта (договора) с
единственным поставщиком (подрядчиком, исполнителем), включены в реестр
российского программного обеспечения и (или) реестр евразийского программного
обеспечения и которое соответствует тому же классу программного обеспечения, что
и программное обеспечение, являющееся объектом закупки (предметом закупки), по
своим функциональным, техническим и (или) эксплуатационным характеристикам не
соответствует установленным заказчиком требованиям к программному
обеспечению, являющемуся объектом закупки (предметом закупки).
Класс программного обеспечения:
Класс программного обеспечения по классификатору, утвержденному
приказом от 22.09.2020 № 486
Основной
12.12 Программное обеспечение для решения отраслевых задач в области
жилищно-коммунального хозяйства
Требования к функциональным, техническим и эксплуатационным
характеристикам программного обеспечения, являющегося объектом закупки,
установленные заказчиком.
Требования к функциональным, техническим и эксплуатационным
характеристикам программного обеспечения, являющегося объектом закупки:
Краткое описание программного обеспечения
Подсистема региональной государственной информационной системы
жилищно-коммунального хозяйства «Учет потребления коммунальных ресурсов
Ленинградской области» предназначена для автоматизации процессов, связанных с
учетом потребления коммунальных ресурсов объектами Ленинградской области и
анализа эффективности потребления коммунальных ресурсов, а также передачи
накопленной информации во внешние системы.
Функциональные характеристики программного обеспечения
– cбор, хранение, обработка и передача сведений и данных от потребителей
коммунальных ресурсов Ленинградской области с целью обеспечения возможности
их анализа;
– оптимизация потребления коммунальных ресурсов;
– контроль работоспособности коммерческого оборудования учета потребления
коммунальных ресурсов;
– выявление нарушений в части потребления, поставки и учета потребления
коммунальных ресурсов;
– контроль потребления коммунальных ресурсов;
Функциональные, технические и (или) эксплуатационные характеристики,
по которым программное обеспечение, соответствующее классу «Операционные
системы», сведения о котором включены в реестр, не соответствует
установленным заказчиком требованиям к программному обеспечению,
являющимся объектом закупки:
Исходя из анализа программ, указанных в Едином реестре российских программ
для электронных вычислительных машин и баз данных, в классе программ
«Программное обеспечение для решения отраслевых задач в области жилищнокоммунального хозяйства» не выявлено ни одного программного обеспечения,
сведения о котором включены в Единый реестр и которое соответствует тому же
классу программного обеспечения, что и программное обеспечение, планируемое к
закупке, и которое по своим функциональным, техническим и эксплуатационным
характеристикам могло бы соответствовать установленным заказчиком требованиям
к планируемому к закупке программному обеспечению.
Названия программного обеспечения, сведения о котором включены в реестр и
которое соответствует тому же классу программного обеспечения, что и программное
обеспечение, являющееся объектом закупки:
1. 20543
Система
диспетчеризации
ЛЭРС
УЧЁТ
ЛЭРС-Р
Класс программного обеспечения по классификатору, утвержденному
приказом от 22.09.2020 № 486
Основной
12.12 Программное обеспечение для решения отраслевых задач в области
жилищно-коммунального хозяйства
Коды продукции
Коды продукции в соответствии с Общероссийским классификатором
продукции по видам экономической деятельности
62 Продукты программные и услуги по разработке программного обеспечения;
консультационные и аналогичные услуги в области информационных
технологий
63.11 Услуги по обработке данных, размещению и взаимосвязанные услуги
Описание программного обеспечения
Краткое описание программного обеспечения
Система диспетчеризации ЛЭРС УЧЁТ предназначена для технологического и
коммерческого учета тепла, воды, пара, газа, электроэнергии.
Поддерживается опрос более 300 моделей приборов учета (счетчиков) разных
производителей.
Область
применения:
объекты
жилищно-коммунального
хозяйства
(поквартирный и общедомовой учет), промышленные и производственные
предприятия.
Функциональные характеристики программного обеспечения
автоматизированное и ручное чтение данных по каждому объекту; анализ
параметров потребления, выявление нештатных ситуаций и рассылка
соответствующих уведомлений. экспорт данных в файлы различных форматов;
подготовка и печать отчетных документов; отображение параметров
потребления виде таблиц и графиков;
Относится к классу -12 «Отраслевое прикладное программное обеспечение».
При этом система не позволяет выгружать информацию в ГИС ЖКХ,
отсутствует возможность интеграции с биллинговыми системами региона.
2. 19827 Система автоматизированная измерительная информационно-расчетная
коммерческого учета энергоресурсов "АИС Город. Приборный учет"
Возможности АИИРС КУЭ «АИС Город. Приборный учет»:
Класс программного обеспечения по классификатору, утвержденному
приказом от 22.09.2020 № 486
Основной
12.12 Программное обеспечение для решения отраслевых задач в области
жилищно-коммунального хозяйства
Коды продукции
Коды продукции в соответствии с Общероссийским классификатором
продукции по видам экономической деятельности
62 Продукты программные и услуги по разработке программного обеспечения;
консультационные и аналогичные услуги в области информационных
технологий
63.11 Услуги по обработке данных, размещению и взаимосвязанные услуги
Описание программного обеспечения
Краткое описание программного обеспечения
Программное обеспечение предназначено для решения задач автоматического
сбора показаний приборов учета, контроля за качеством оказания услуг по
энергоснабжению, учету работ на объектах, контролю поверок приборов учета и
построению иерархии ресурсоснабжения и баланса потребления энергоресурсов
по объектам.
Функциональные характеристики программного обеспечения
Возможности АИИРС КУЭ «АИС Город. Приборный учет»:
– Наличие модулей формирования планов работ;
– Готовность к выгрузке информации в ГИС ЖКХ;
– Возможность интеграции с биллинговыми системами с автоматическим
расчётом объема потребленных ресурсов;
– Хранимые архивы полученных показаний ограничены серверными
мощностями, а не памятью прибора учета;
– Возможность дополнительного расчета параметров, не предусмотренных
стандартным протоколом опроса;
– Возможность одновременной работы с квартирными и общедомовыми
счетчиками;
– Исключение человеческого фактора из процессов снятия показаний;
– Поддержка большого количества разных типов приборов учета и УСПД;
– Совмещение функций учета и оперативного мониторинга/диспетчеризации
сетей;
– Существенное сокращение затрат на эксплуатацию за счет единой программнотехнической платформы для всех видов энергоресурсов;
– Оперативный контроль количества и качества энергоресурсов с передачей
учетных данных в расчетные (биллинговые) центры;
– Управление потреблением энергоресурсов;
– Оперативный мониторинг состояния всех инженерных коммуникаций (сетей) и
автоматическое информирование аварийных служб и МЧС об аварийных
ситуациях;
– Формирование отчетов о потреблении энергоресурсов, оперативный
мониторинг показателей энергоэффективности.
Относится к классу -12 «Отраслевое прикладное программное обеспечение».
При этом система не позволяет осуществить интеграционное взаимодействие с
внешними система Ленинградской области, таких как: ГИС ТЭК, РГИС
«Энергоэффективность», с целью оптимизации процессов в сегменте жилищнокоммунальных услуг региона.
3. 17686 Интерсвязь. Платформа сбора данных с приборов учета (partner)
Класс программного обеспечения по классификатору, утвержденному
приказом от 22.09.2020 № 486
Основной
02.03 Средства обеспечения облачных и распределенных вычислений
Дополнительные
12.20 Информационные системы для решения специфических отраслевых задач
Коды продукции
Коды продукции в соответствии с Общероссийским классификатором
продукции по видам экономической деятельности
63.11 Услуги по обработке данных, размещению и взаимосвязанные услуги
Описание программного обеспечения
Краткое описание программного обеспечения
Интерсвязь. Платформа сбора данных с приборов учета (partner) позволяет
производить сбор данных с приборов учета, автоматизированное подключение
прибора учета к системе. Возможность изменения интерфейса (ребрейдинг) по
желанию заказчика.
Функциональные характеристики программного обеспечения
Программное обеспечение «Интерсвязь Платформа сбора данных с приборов
учета (partner)» предоставляет возможность сбора, мониторинга, выгрузки
данных с приборов учета, расположенных в жилых/нежилых помещениях.
Пользователями данного ПО являются как операторы связи, так и управляющие
компании. Данное ПО облегчает сбор с данных приборов учета и делает данную
процедуру автономно и автоматизировано. Наличие функции White-label
позволяет распространять данное ПО под своим брендом, настраивая нужную
цветовую тему и загружая собственный логотип.
Относится к классу -12 «Отраслевое прикладное программное обеспечение».
При этом в Системе отсутствуют следующие функциональные возможности:
– Наличие модулей формирования планов работ;
– Готовность к выгрузке информации в ГИС ЖКХ;
– Возможность интеграции с биллинговыми системами с автоматическим
расчётом объема потребленных ресурсов;
– Хранимые архивы полученных показаний
мощностями, а не памятью прибора учета;
ограничены
серверными
– Возможность дополнительного расчета параметров, не предусмотренных
стандартным протоколом опроса;
– Возможность одновременной работы с квартирными и общедомовыми
счетчиками;
– Исключение человеческого фактора из процессов снятия показаний;
– Поддержка большого количества разных типов приборов учета и УСПД;
– Совмещение функций учета и оперативного мониторинга/диспетчеризации
сетей;
– Существенное сокращение затрат на эксплуатацию за счет единой программнотехнической платформы для всех видов энергоресурсов;
– Оперативный контроль количества и качества энергоресурсов с передачей
учетных данных в расчетные (биллинговые) центры;
– Управление потреблением энергоресурсов;
– Оперативный мониторинг состояния всех инженерных коммуникаций (сетей) и
автоматическое информирование аварийных служб и МЧС об аварийных
ситуациях;
– Формирование отчетов о потреблении энергоресурсов, оперативный
мониторинг показателей энергоэффективности. При этом система не позволяет
осуществить интеграционное взаимодействие с внешними система
Ленинградской области, таких как: ГИС ТЭК, РГИС «Энергоэффективность», с
целью оптимизации процессов в сегменте жилищно-коммунальных услуг
региона. Кроме того, система не позволяет осуществить интеграционное
взаимодействие с внешними система Ленинградской области, таких как: ГИС
ТЭК, РГИС «Энергоэффективность», с целью оптимизации процессов в сегменте
жилищно-коммунальных услуг региона и выгружать информацию в ГИС ЖКХ,
отсутствует возможность интеграции с биллинговыми системами региона

=== ФАЙЛ: Приложение № 1. Описание объекта закупки_001.docx | docs/0145200000426001424/Приложение № 1. Описание объекта закупки_001.pdf
УТВЕРЖДАЮ
Директор государственного казенного
учреждения Ленинградской области
«Центр энергосбережения и повышения
энергоэффективности Ленинградской
области»
___________________ Н.А. Лазаревич
(подпись)
«______»__________________20____г.
М.П.
ОПИСАНИЕ ОБЪЕКТА ЗАКУПКИ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития
Подсистемы «Учет потребления коммунальных ресурсов Ленинградской области»
Техническое задание на 89 листах
СОГЛАСОВАНО
СОГЛАСОВАНО
Председатель комитета по топливноэнергетическому комплексу
Ленинградской области
Председатель комитета цифрового
развития Ленинградской области
______
____________С.С. Морозов
(подпись)
«_____» _______________20____г.
___________________ А.С. Сытник
(подпись)
«_____» _______________20____г.
М.П.
М.П.
Санкт-Петербург
2026 г.
ОГЛАВЛЕНИЕ
Принятые термины и сокращения................................................................................. 6
1 Общие сведения............................................................................................................9
1.1 Полное наименование Подсистемы и ее условное обозначение.......................9
1.2 Заказчик Подсистемы............................................................................................ 9
1.3 Исполнитель работ................................................................................................. 9
1.4 Место выполнения работ.......................................................................................9
1.5 Нормативно-правовые акты обеспечения работ...............................................10
1.6 Плановые сроки начала и окончания работ по развитию Подсистемы..........12
1.7 Сведения об источниках и порядке финансирования работ............................12
2 Цели и назначение автоматизированной Подсистемы...........................................13
2.1 Цель создания Подсистемы.................................................................................13
2.2 Назначение Подсистемы......................................................................................13
3 Характеристики объекта автоматизации.................................................................15
3.1 Основные сведения об объекте автоматизации................................................15
3.2 Состав Подсистемы..............................................................................................16
4 Требования к автоматизированной Подсистеме.....................................................19
4.1 Требования к структуре Подсистемы в целом..................................................19
4.2 Требования к выполнению работ.......................................................................21
5 Требования к видам обеспечения............................................................................. 22
5.1 Требования к математическому обеспечению Подсистемы............................22
5.1.1 Требования к составу, структуре и способам организации данных................................22
5.1.2 Требования к информационному обмену между компонентами Подсистемы и со
смежными ИСиС............................................................................................................................23
5.1.3 Требования к информационной совместимости со смежными ИСиС............................23
5.1.4 Требования по применению систем управления базами данных....................................29
5.1.5 Требования к представлению данных в подсистеме.........................................................29
5.1.6 Требования к контролю, хранению, обновлению и восстановлению данных..............29
5.2 Требования к лингвистическому обеспечению Подсистемы..........................30
5.2.1 Требования к языкам, используемым в Подсистеме.........................................................30
5.2.2 Требования к способам организации диалога...................................................................30
5.2.3 Требования к разработке и использованию словарей, тезаурусов..................................30
5.2.4 Требования к описанию синтаксиса формализованного языка.......................................30
5.3
Требования к программному обеспечению Подсистемы............................30
5.3.1 Требования к составу и видам программного обеспечения.............................................30
5.3.2 Требования к выбору используемого программного обеспечения.................................31
5.3.3 Требования к разрабатываемому программному обеспечению.......................................31
2
5.3.4 Требования к покупным программным средствам...........................................................32
5.4 Требования к техническому обеспечению........................................................32
5.4.1 Требования к системно-технической инфраструктуре.....................................................32
5.4.2 Требования к автоматизированным рабочим местам.......................................................33
5.4.3 Требования к функциональным группам серверов...........................................................33
5.5 Требования к метрологическому обеспечению................................................34
5.6 Требования к организационному обеспечению................................................34
5.6.1 Требования к порядку организации работы при сбоях и нештатных ситуациях...........34
5.7 Требования к методическому обеспечению......................................................36
6 Общие технические требования к Подсистеме.......................................................37
6.1 Требования к надежности Подсистемы.............................................................37
6.2 Требования по конфиденциальности.................................................................38
6.3 Требования к эргономике и технической эстетике...........................................40
6.4 Требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов Подсистемы.......................................................................41
6.5 Требования к сохранности информации при авариях......................................42
6.6 Требования к защите от влияния внешних воздействий..................................43
6.7 Требования к патентной чистоте и патентоспособности.................................43
7 Состав и содержание работ по развитию подсистемы...........................................46
7.1 Требования к безопасности выполнения работ.................................................46
7.2 Требования к сроку и объему предоставления гарантий качества работ.......46
7.3 Требования к объему работ................................................................................. 47
8 Порядок развития автоматизированной Подсистемы............................................49
8.1 Порядок развития Подсистемы...........................................................................49
8.2 Разработка функциональной возможности выбора периода графика и
реестра в функциональном модуле «Контроль превышения фактического
теплопотребления от проектного» раздела «Энергоэффективность»...................51
8.2.1 Реализовать отображение данных за период «с, по» для раздела «График»..................51
8.2.2 Реализовать отображение данных за период для раздела Карта.....................................52
8.2.3 Реализовать отображение данных за период для раздела Реестр....................................52
8.2.4 Реализовать печатную форму отчета..................................................................................52
8.3 Разработка функциональной возможности выбора периода в модуле
«Контроль температурного графика» раздела «Энергоэффективность».............53
8.3.1 Реализовать отображение данных за период для раздела График...................................53
8.3.2 Реализовать отображение данных за период для раздела Карта.....................................54
8.3.3 Реализовать отображение данных за период для раздела Реестр....................................54
8.3.4 Реализовать печатную форму отчета..................................................................................54
8.4 Разработка печатной формы «Контроль температурного графика» по
объекту потребления..................................................................................................55
3
8.4.1 Реализовать возможность формировать отчет по конкретному объекту........................55
8.4.2 Добавить возможность формировать отчет «Контроль температурного графика» из
дерева объектов..............................................................................................................................56
8.5 Доработка модуля «Реестры» в разделе формирования отчетности
«Сверхнормативное потребление тепловой энергии», в части доработки выбора
района при формировании отчета............................................................................56
8.5.1 Добавить возможность выбора района...............................................................................56
8.5.2 Запретить выбирать головной прибор, если не указан объект головного прибора.......57
8.6 Добавление механизмов расчета рекомендуемого расхода для
температурных графиков...........................................................................................57
8.6.1 Разработка функции расчета рекомендуемого расхода для температурного графика на
обратном трубопроводе.................................................................................................................57
8.6.2 Разработка печатной формы для рекомендуемого расхода по объекту..........................58
8.7 Разработка интерактивного виджета на стартовой странице с
функциональной информацией по перерасходу тепловой энергии от
нормативного показателя в денежном выражении.................................................58
8.8 Доработка формирования отчета в модуле «Реестры», раздел «Превышение
лимитов потребления» в части выбора муниципального образования без
привязки к подключенным объектам.......................................................................59
8.9 О замене системы управления базами данных в целях импортозамещения и
повышения уровня защиты информации....................................................................59
9 Порядок контроля и приемки Подсистемы.............................................................61
9.1 Виды испытаний и внедрение доработанной Подсистемы..............................61
9.2 Проведение профилактических работ................................................................64
9.3 Передача исходных кодов...................................................................................64
9.4 Общие требования к приемке работ...................................................................65
9.5 Требования информационной безопасности при проведении работ по
развитию информационной системы.......................................................................67
9.5.1 Требования информационной безопасности..................................................67
9.5.2 Требования к наличию лицензий.....................................................................68
9.5.3 Требования к удаленному доступу..................................................................71
9.5.4. Требования к разработке организационных, организационно – технических
и распорядительных документов по информационной безопасности при
осуществлении развития ГИС ЛО...............................................................................72
9.5.5 Требования к моделированию угроз безопасности...........................................73
9.5.6 Требования к устранению уязвимостей.............................................................76
10 Требования к составу и содержанию работ по подготовке Подсистемы к вводу
в действие....................................................................................................................... 78
11 Требования к документированию...........................................................................79
12 Источники разработки.............................................................................................81
13 ПРИЛОЖЕНИЯ........................................................................................................83
4
5
Принятые термины и сокращения
Термин/ наименование
/сокращение
Подсистема
ИС
Контракт
Работы
Исполнитель
Пользователь
Подсистемы
Развитие Подсистемы
Мониторинг
Надежность Подсистемы
API
ПО
СУБД
Определение/ описание
Подсистема региональной государственной информационной
системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов
Ленинградской области»
Информационная система взаимосвязанная совокупность средств,
методов и персонала, используемых для сбора, хранения,
обработки, анализа и выдачи информации в интересах достижения
определённых целей
Государственный контракт на выполнение работ по развитию
Подсистемы региональной государственной информационной
системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов
Ленинградской области»
Работы по развитию Подсистемы региональной государственной
информационной системы жилищно-коммунального хозяйства
Ленинградской области «Учет потребления коммунальных
ресурсов Ленинградской области»
Юридическое / физическое лицо, индивидуальный
предприниматель, с которым Заказчиком заключен
Государственный контракт на выполнение работ по развитию
Подсистемы в соответствии с Федеральным законом № 44-ФЗ от
05.04.2013 года «О контрактной системе в сфере закупок товаров,
работ, услуг для обеспечения государственных и муниципальных
нужд»
Пользователями системы являются поставщики информации,
(указанные в пункте 24 и 25 Терминов и определений к
настоящему ООЗ, пользователи ГИС ТЭК), имеющие доступ к
Подсистеме и использующие ее функционал, органы
исполнительной власти, органы местного самоуправления,
ресурсоснабжающие организации
Деятельность по выполнению работ, необходимых для
обеспечения устойчивого функционирования Подсистемы,
актуализации функциональных возможностей Подсистемы
согласно функциональным требованиям
Процесс систематического или непрерывного сбора информации
о параметрах сложного объекта или процесса
Комплексное свойство системы сохранять во времени
в установленных пределах значения всех параметров,
характеризующих способность системы выполнять свои функции
в заданных режимах и условиях эксплуатации
API (интерфейс прикладного программирования) - описание
способов (набор классов, процедур, функций, структур или
констант), которыми одна компьютерная программа может
взаимодействовать с другой программой
Программное обеспечение
Система управления базами данных
6
ЦОД ЛО
АРМ
ГОСТ
Инцидент
Аутентификация
БД
Внешние системы
Время выполнения
ГАР
УПКР
Запрос
Идентификация
Конвертация данных
ОМС
ООЗ
Поставщики информации
РСО
Электронный запрос
АСКУЭ
ЕИС
ЕСИА
ЕСПД ЛО
ФСТЭК
Центр обработки данных правительства Ленинградской области
Автоматизированное рабочее место
Государственный стандарт
Любое событие, не являющееся частью стандартного (штатного)
использования Подсистемы, которое привело или могло привести
к прерыванию или невозможности использования Подсистемы
Процесс подтверждения прав на использование идентификатора
База данных - совокупность данных, организованных в
соответствии с концептуальной структурой, описывающей
характеристики этих данных и взаимоотношения между ними,
которая поддерживает одну или более областей применения
РГИС Энергосбережения Ленинградской области, прочие
информационные системы
Время, прошедшее с момента поступления Запроса до направления
уведомления пользователю о завершении работы по Запросу
Государственный адресный реестр, содержащий информацию об
адресах в муниципальном делении
Подсистема РГИС ЖКХ ЛО «Учет потребления коммунальных
ресурсов Ленинградской области»
Запрос, связанный с событием, которое не является частью
нормальной/текущей/операционной работы Подсистемы,
ситуация, в которой выявлен дефект или стабильно
повторяющиеся дефекты
Процесс распознавания субъекта в компьютерной системе при
помощи анализа его идентификатора
Преобразование данных из одного формата в другой, с
сохранением основного логически-структурного содержания
информации
Органы местного самоуправления Ленинградской области
Описание объекта закупки
Эксплуатанты зданий, органы местного самоуправления,
ресурсоснабжающие организации Ленинградской области, ЛОГКУ
«Центр энергосбережения и повышения энергоэффективности
Ленинградской области»
Ресурсоснабжающие организации
Запрос информации в рамках межведомственного взаимодействия
посредством API
Автоматизированная система коммерческого учёта электроэнергии
Единая информационная система в сфере закупок
Единая система идентификации и аутентификации
Единая сеть передачи данных Ленинградской области
Федеральная служба по техническому и экспортному контролю
7
Российской Федерации
ФИАС
ИСиС
ЭД
ОРД
МУ
ЦУС
ПЭВМ
JSON
Федеральная информационная адресная система
Информационные сети и системы
Эксплуатационная документация
Организационно-распорядительная документация
Муниципальное учреждение
Целевой уровень снижения энергопотребления
Персональная электронная вычислительная машина
Текстовый формат обмена данными
8
1
ОБЩИЕ СВЕДЕНИЯ
В настоящем документе представлено техническое задание на выполнение
работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития
Подсистемы «Учет потребления коммунальных ресурсов Ленинградской области».
1.1
Полное наименование Подсистемы и ее условное обозначение
Полное
наименование
информационной
Подсистемы:
региональная
государственная информационная система жилищно-коммунального хозяйства
Ленинградской области в части Подсистемы «Учет потребления коммунальных
ресурсов Ленинградской области».
Регистрационный номер ИС: 1-07-0-00-01.
Дата регистрации: 22.05.2018 г.
Краткое наименование: РГИС ЖКХ УПКР ЛО, Подсистема.
1.2
Заказчик Подсистемы
Заказчик, оператор: Государственное казённое учреждение Ленинградской
области
«Центр
энергосбережения
и
повышения
энергоэффективности
Ленинградской области» (далее – ГКУ ЛО «ЦЭПЭ ЛО»).
Функциональный заказчик – комитет по топливно-энергетическому
комплексу Ленинградской области (далее – комитет по ТЭК ЛО).
1.3
Исполнитель работ
Исполнитель определяется в соответствии с Федеральным законом от 5
апреля 2013 года № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ,
услуг для обеспечения государственных и муниципальных нужд».
1.4
Место выполнения работ
Санкт-Петербург и Ленинградская область. Подсистема развернута на
аппаратных мощностях ЦОД Правительства Ленинградской области по адресу
Выборгское шоссе, д. 503, корп. 12.
Адрес
заказчика:
ГКУ
ЛО
«ЦЭПЭ
ЛО»:
Санкт-Петербург
муниципальный округ Смольнинское вн.тер.г., Калужский пер., 3 А.
9
г.,
Адрес функционального заказчика: Комитет по ТЭК ЛО: г. СанктПетербург, ул. Смольного, д. 3.
1.5
Нормативно-правовые акты обеспечения работ
 Федеральный закон от 27.07.2006 г. № 149-ФЗ «Об информации,
информационных технологиях и о защите информации»;
 Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности
критической
информационной
инфраструктуры
Российской
Федерации»;
 Федеральный закон от 21.07.2014 № 209-ФЗ «О государственной
информационной системе жилищно-коммунального хозяйства»;
 Указ Президента Российской Федерации от 17.03.2008 г. № 351 «О
мерах по обеспечению информационной безопасности Российской
Федерации при использовании информационно-телекоммуникационных
сетей международного информационного обмена»;
 Указ Президента Российской Федерации от 30.03.2022 г. № 166 «О
мерах по обеспечению технологической независимости и безопасности
критической
информационной
инфраструктуры
Российской
Федерации»;
 Постановление Правительства Российской Федерации от 16.11.2015 г.
№ 1236 «Об утверждении правил формирования и ведения единого
реестра российских программ для электронных вычислительных машин
и баз данных и единого реестра программ для электронных
вычислительных машин и баз данных из государств - членов
евразийского экономического союза, за исключением российской
федерации»;
 Постановление Правительства Российской Федерации от 06.07.2015 №
676 «О требованиях к порядку создания, развития, ввода в
эксплуатацию,
эксплуатации
и
вывода
из
эксплуатации
государственных информационных систем, и дальнейшего хранения
содержащейся в их базах данных информации»;
10
 Постановление
Правительства
лицензировании
РФ
деятельности
от
03.02.2012
№
по
технической
79
«О
защите
конфиденциальной информации»;
 Областной закон Ленинградской области от 18.07.2016 № 60-оз
«О государственных
информационных
системах
Ленинградской
области»;
 Постановление Правительства Ленинградской области от 14.11.2013 №
395 «Об утверждении государственной программы Ленинградской
области «Цифровое развитие Ленинградской области»;
 Постановление Правительства Ленинградской области от 14.11.2013 №
400 «Об утверждении государственной программы Ленинградской
области "Обеспечение устойчивого функционирования и развития
коммунальной
и
инженерной
инфраструктуры
и
повышение
энергоэффективности в Ленинградской области»;
 Приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении
Требований о защите информации, содержащейся в государственных
информационных
системах,
иных
информационных
системах
государственных органов, государственных унитарных предприятий,
государственных учреждений»;
 ГОСТ Р 50922-2006 «Защита информации. Основные термины и
определения»;
 ГОСТ
Р
56545-2015
«Защита
информации.
Уязвимости
информационных систем. Правила описания уязвимостей»;
 ГОСТ
Р
59793-2021
«Информационные
технологии.
Комплекс
стандартов на автоматизированные системы. Автоматизированные
системы. Стадии создания»;
 ГОСТ
Р
стандартов
59792-2021
на
«Информационные
автоматизированные
автоматизированных систем».
11
технологии.
системы.
Виды
Комплекс
испытаний
Объектами автоматизации являются процессы, связанные с учетом
потребления коммунальных ресурсов объектами Ленинградской области и анализ
эффективности потребления коммунальных ресурсов, и передача накопленной
информации во внешние системы.
1.6
Плановые сроки начала и окончания работ по развитию Подсистемы
Срок выполнения работ: в соответствии с разделом 8.1 ООЗ:
Начало: С момента заключения государственного контракта.
Окончание: не позднее 14.12.2026 г.
1.7
Сведения об источниках и порядке финансирования работ
Источник
финансирования
работ
по
развитию
региональной
государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области в части развития Подсистемы «Учет потребления
коммунальных ресурсов Ленинградской области» – бюджет Ленинградской
области (в рамках исполнения Областного закона Ленинградской области от
20.12.2024 № 178-оз «Об областном бюджете Ленинградской области на 2025 год и
на плановый период 2026 и 2027 годов»).
12
2
ЦЕЛИ И НАЗНАЧЕНИЕ АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЫ
Подсистема региональной государственной информационной системы
жилищно-коммунального хозяйства «Учет потребления коммунальных ресурсов
Ленинградской области» предназначена для автоматизации процессов, связанных с
учетом потребления коммунальных ресурсов объектами Ленинградской области и
анализа эффективности потребления коммунальных ресурсов, а также передачи
накопленной информации во внешние системы.
2.1
Цель создания Подсистемы
Основными целями являются:
 оптимизация потребления коммунальных ресурсов;
 контроль работоспособности коммерческого оборудования учета
потребления коммунальных ресурсов;
 контроль потребления коммунальных ресурсов;
 выявление нарушений в части потребления, поставки и учета
потребления коммунальных ресурсов.
2.2
Назначение Подсистемы
Подсистема обеспечивает решение следующих задач при условии
получения и использования достоверной и актуальной информации:
 Сбор, хранение, обработка и передача сведений и данных от
потребителей коммунальных ресурсов Ленинградской области с целью
обеспечения возможности их анализа и использования в целях
повышения информационной открытости и качества управленческих
решений в регионе, а также их передачи во внешние системы (РГИС
«Энергоэффективность», Подсистема модуль «ТЭК ЛО», ФГИС
«АРШИН»);
 Организация в Ленинградской области источника данных о качестве
поставляемых коммунальных услуг для потребителей;
 Организация в Ленинградской области единого источника данных о
характеристиках учета коммунальных услуг;
13
 Организация в Ленинградской области получения объективных данных
о потреблении государственными и муниципальными учреждениями
Ленинградской области и населением (при наличии узла учета,
установленного на объекте и подключенного к информационной
Подсистеме) коммунальных ресурсов;
 Организация в Ленинградской области совершенствования механизма
расчета и повышения достоверности расчета необходимой валовой
выручки ресурсоснабжающих организаций и оптимизации процесса
выплаты субсидии РСО в связи с установлением льготных тарифов на
коммунальные
ресурсы
водоснабжения,
теплоснабжения
и
водоотведения, реализуемые населению на территории Ленинградской
области.
В Подсистеме предусмотрены сбор и хранение данных о поставляемых
коммунальных услугах учреждениям, для последующего получения объективных
данных о потреблении государственными и муниципальными учреждениями
Ленинградской области и населением (при наличии узла учета, установленного на
объекте и подключенного к информационной Подсистеме) коммунальных
ресурсов: теплоснабжения, водоснабжения и водоотведения, электроэнергии.
Получение таких данных производится путем установки передающих
устройств на государственных и муниципальных учреждениях, многоквартирных
жилых домах Ленинградской области, консолидации данных и передачи
консолидированных данных с настройкой шифрования по «ГОСТ Р 34.12-2015.
Национальный стандарт Российской Федерации. Информационная технология.
Криптографическая защита информации. Блочные шифры».
Основной задачей Исполнителя является развитие Подсистемы, в части
выполнения работ, для формирования отчетности и проведения аналитических
мероприятий, также настройка разграничения прав доступа, актуализация
справочников
и
отчетных
форм,
исправление
ошибок
и
актуализация
возможностей системы, синхронизация с государственными информационными
системами, обработка данных.
14
3
ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ
Объектом
развития
является
региональная
государственная
информационная Подсистема жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов Ленинградской области».
3.1
Основные сведения об объекте автоматизации
Компоненты
Подсистемы
обеспечивающему
раздельное
функциональных
приложений
построены
по
функционирование
и
модульному
и
принципу,
хранение
Web-ориентированных
данных
интерфейсов
пользователей.
В состав архитектуры РГИС ЖКХ ЛО входят следующие основные
серверные компоненты:
Рисунок 3.1 – Схема структурная Подсистемы
В Подсистеме осуществляется журналирование всех событий и действий
пользователей в Подсистеме. Журналы событий составлены в форме доступной для
проведения последующего анализа взаимодействия пользователей в Подсистеме,
15
модулей системы между собой и системы с внешними системами. Подсистема
взаимодействует с существующей инфраструктурой РГИС ЖКХ ЛО и другими
государственными информационными системами, в том числе в части единых
справочников.
Все
компоненты
Подсистемы
размещены
в
ЦОД
Правительства
Ленинградской области.
3.2
Состав Подсистемы
В состав Подсистемы входят следующие уровни обработки данных:
 Уровень источника данных, обеспечивающий фиксацию и сбор
событийной, визуальной и иной необходимой информации;
 Уровень средств вычислительной техники и средств информационного
обмена,
обеспечивающий
накопление
и
первичный
анализ
и
дальнейшую передачу информации, собранной на первом уровне
информации;
 Уровень программно-технических комплексов объектов мониторинга,
обеспечивающий
реструктуризацию
накопленной
и
проанализированной на втором уровне информации;
 Уровень
программно-технического
комплекса
центра
обработки
данных, обеспечивающий унифицированное представление событий на
объектах мониторинга для персонала, а также ретроспективный анализ
обработанной на третьем уровне информации.
Передача между разными уровнями событийной, визуальной и иной
требуемой для информирования персонала осуществляется средствами сетевого
взаимодействия.
В состав программно-технического комплекса центра обработки данных
входят следующие компоненты и программные службы:
 Сервер-коллектор первичной информации от инженерных систем:
 Подсистема сбора, консолидации и агрегации данных с первичного
инженерного оборудования;
16
 Подсистема
обогащения
событийной
информации
за
счет
инструментов расчета промежуточных показаний и агрегационных
функций;
 Сервер обеспечения работы бизнес-логики приложений:
 Подсистема сбора данных от инженерного оборудования;
 Подсистема ведения электронных паспортов объектов;
 Подсистема авторизации и аутентификации пользователей;
 Сервер визуализации, предоставляющий доступ к аналитической и
оперативной
информации,
формирующей
унифицированное
представление деятельности на контролируемых объектах в реальном
времени:
 Рабочее место главного диспетчера;
 Рабочее место диспетчера;
 Рабочее место главного инженера;
 Рабочее место ответственного за потребление коммунальных
ресурсов;
 Рабочее место мастера участка;
 Подсистема формирования отчетов;
 Мобильное
приложение
исполнителя
работ
и
оператора
диспетчерского центра;
 Оповещения о новых заявках;
 Контроль инженерного оборудования в обслуживаемых школах;
 Контроль аварийных ситуаций на инженерных системах.
Все
компоненты
Подсистемы
размещены
в
ЦОД
Правительства
Ленинградской области.
Используемое в составе Подсистемы программно-техническое обеспечение
представлено в таблице 3.1.
Таблица 3.1 – Программно-технические характеристики Подсистемы
№
п/п
Класс программного
обеспечения
Наименование
программного
обеспечения
Производитель
программного
обеспечения
17
Количество
Общее программное обеспечение
1
2
3
4
5
6
Операционные
РЕД ОС версия
ООО «РЕД СОФТ»
системы
7.3.
Открытая платформа .NET 8
Microsoft
для разработки
многоплатформенных
приложений
Подсистемы
PostgreSQL 14
ООО "ПОСТГРЕС
управления базами
ПРОФЕССИОНАЛЬНЫЙ"
данных
Специальное программное обеспечение
Платформа
dockerDocker, Inc
контейнеризации с
ce.x86_64.3:26.1.4открытым исходным 1.el7
кодом для
разработчиков и ИТспециалистов для
работы с кодами
Библиотека
jQuery v3.6.0
jQuery Board
JavaScript,
фокусирующаяся на
взаимодействии
JavaScript и HTML
Серверное и
Nginx angie-1.6.2- NGINX Inc
связующее ПО
1.el7.x86\_643
18
1
1
1
1
1
1
4
ТРЕБОВАНИЯ К АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЕ
4.1
Требования к структуре Подсистемы в целом
Функционалы,
которые
должны
поддерживаться
в
актуальном
и
работоспособном состоянии:
 Удаленный мониторинг объектов с помощью автоматизированного
рабочего места;
 Удаленный
мониторинг
ситуации
на
объектах
для
предотвращения/фиксации нештатных ситуаций;
 Передача оперативных данных о текущем состоянии систем и их вывод
на экраны Заказчика;
 Накопление, обработку и хранение информации, поступающей с
технических систем с обеспечением возможности анализа хранимой
информации, формирования отчетов;
 Формирование информационных сообщений с целью привлечения
внимания пользователей при возникновении нештатных ситуаций на
уровне прибора;
 Сбор и передачу данных со всех интегрированных систем в единое
хранилище данных с последующей обработкой по заранее заданным
алгоритмам;
 Сервер визуализации должен обеспечивать отображения оперативной
информации из систем объектов и параметров работы локальных систем
объектов;
 Визуальное отображение данных должно производиться в обобщенной
форме, в удобном и наглядном виде. События и инциденты должны
отображаться в оперативном режиме на карте города и планах объектов;
 Визуализация должна охватывать следующие уровни иерархии:
 Объекты мониторинга на интерактивной карте региона;
 Поэтажные схемы по каждому отдельному объекту.
 Сервер визуализации:
19
 Отображает данные об общем состоянии объекта мониторинга
на интерактивной карте региона;
 Отображает события/инциденты на схеме выбранного объекта;
 Просматривает
историю событий с возможностями их
фильтрации и группировки;
 Отображает динамику ключевых событий на графических
схемах с возможностями их фильтрации и группировки;
 Обеспечивает отображение информации в удобной и наглядной
форме на карте города и планах с детализацией необходимых
характеристик по отдельным объектам;
 Средства аналитики и построения отчетов обеспечивает:
 Хранение,
обмен
и
отображение
информации
в
унифицированном виде;
 Выгрузку основных данных в структурированном виде для
дальнейшей обработки вне Подсистемы;
 Построение отчетов в разрезе различных видов информации:
 Отчет о сбоях в работе технических средств;
 Отчет о внештатных ситуациях;
 Политика разграничения доступа и функциональности с учетом
заложенной ролевой модели;
 Администрирование объектов потребления - Право управления
объектами, адресами, договорами и привязками;
 Администрирование организации - Полный доступ к управлению
организацией;
 Администрирование системы - Полный доступ в систему без
ограничения прав доступа;
 Администрирование устройств - Право добавления и настройки
приборов учета;
 Аналитическая деятельность - Право настраивать уставки, право
доступа к ресурсонабжению и анализу энергоэффективности;
 Отчетная деятельность - Право формировать все виды отчетов;
20
 Просмотр объектов потребления - Право просмотра объектов,
адресов, договоров и привязок;
 Просмотр устройств - Право просмотра приборов учета;
 Экономическая деятельность - Право доступа к предбиллингу;
 В Подсистеме реализован механизм контроля доступа, обеспечивающий
аутентификацию пользователей при доступе ко всем компонентам
системы.
4.2
Требования к выполнению работ
Для выполнения работ надлежащего качества Исполнитель реализует
выполнение следующих мероприятий:
 Оптимизация производительности системы;
 Повышение качества и удобства пользовательских интерфейсов в
Подсистеме;
 Обеспечение
совместимости
новой
версии
Подсистемы
с
существующими модулями и инфраструктурой Заказчика;
 Обеспечение информационной безопасности, включая защиту
каналов связи, данных Пользователей и ведение журналов действий
в Подсистеме;
 Ведение и актуализация технической документации по Подсистеме,
включая документацию по обновлениям, архитектуре и интерфейсам
взаимодействия;
 Обеспечение процедуры управления изменениями с предварительным
согласованием, тестированием и фиксацией всех изменений в системе;
 Регулярное резервное копирование и проверка восстановления данных;
 Тестирование новых функций перед вводом в эксплуатацию;
 Проведение обучения пользователей и консультаций по возникающим
вопросам;
 Разработка и согласование с Заказчиком стратегического плана развития
Подсистемы на основе текущих потребностей и будущих тенденций.
21
5
ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ
5.1
Требования к математическому обеспечению Подсистемы
Дополнительные требования к математическому обеспечению Подсистемы
не предъявляются.
5.1.1
Требования к составу, структуре и способам организации данных
Состав, структура и способы организации данных и метаданных в
Подсистеме должны учитывать особенности предметной области. В состав
информационного обеспечения Подсистемы должны входить:
 оперативные данные – структурированная информация, которая должна
быть размещена в базе данных Подсистемы;
 электронные образы документов – неструктурированная информация,
которая должна быть размещена в файловом хранилище данных;
 служебная информация – структурированная информация, касающаяся
функционирования Подсистемы и размещаемая в служебных БД;
 нормативно-справочная информация (НСИ) – структурированная
условно-постоянная информация, размещенная в БД Подсистемы;
 внешние информационные ресурсы – структурированная информация,
принимаемая
от
других
автоматизированных
систем
(согласно
соглашениям об информационном обмене и техническим условиям
обмена) и размещаемая в БД Подсистемы;
 метаданные – структурированная информация об информационном
обеспечении Подсистемы, размещенная в служебных БД;
 формы
и
форматы
представления
выходных
документов
–
структурированная информация о содержании, оформлении и формате
представления выходных документов Подсистемы, размещенная в
служебных БД или файловом хранилище документов.
22
5.1.2
Требования к информационному обмену между компонентами
Подсистемы и со смежными ИСиС
Для тестирования информационного обмена Подсистемы со смежными
ИСиС должны использоваться тестовые площадки и тестовые учетные данные,
которые предоставляются Исполнителю Заказчиком работ.
Для обмена с внешними системами в приоритете должен быть использован
структурированный формат данных JSON. В случае, если формат JSON не
поддерживается смежной ИСиС, Исполнитель самостоятельно выбирает форматы
обмена и организует очереди обмена данными в соответствии с требованиями
смежной ИСиС.
В случае использования транспортных файлов, должны быть использованы
форматы XML, DBF, XLS и XLSX. Данные в файлах должны быть
структурированы и приведены к первой нормальной форме.
5.1.3
Требования к информационной совместимости со смежными ИСиС
Подсистема должна быть разработана с учетом принципов открытости и
поддерживать возможность взаимодействия по ключевым задачам через
программный интерфейс (API). Программный интерфейс должен быть построен в
соответствии с принципами RESTfull.
В случае изменений в структуре данных или форматах обмена, Подсистема
должна поддерживать управление версиями API, чтобы избежать конфликтов и
ошибок при синхронизации информации.
Инструментами Подсистемы, должна быть обеспечена возможность
мониторинга и аудита операций обмена данными со смежными ИСиС для
обеспечения прозрачности и контроля над процессами.
Запросы во внешние системы выполняются в соответствии с требованиями,
предъявляемыми в документации на внешние смежные и зашифрованы по
стандарту HTTPS over TLS.
При проектировании Подсистемы должны быть учтены актуальные
существующие решения по защите информации ИС, согласно требованиям
ФСТЭК,
с которыми
планируется
взаимодействие
23
Подсистемы,
а
также
реализованы механизмы взаимодействия с инфраструктурными сервисами
Заказчика в случае необходимости.
Способы взаимодействия со смежными ИС, а также получаемые из них
данные представлены в таблице №5.1.3-1
24
Таблица №5.1.3-1 – Информация о наличии и характере интеграционных взаимодействий Подсистемы с ИС
Наименование ИС
РГИС
«Энергоэффективност
ь ЛО»
Владелец: ГКУ ЛО
«ЦЭПЭ ЛО»
Подсистема (модуль)
«ТЭК ЛО».
Владелец: ГКУ ЛО
«ЦЭПЭ ЛО»
Место
расположения
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
Краткое описание ИС
Региональная
государственная
информационная
система по управлению
энергосбережением и
энергетической
эффективностью
региона,
энергосервисной
деятельностью, ведению
региональной
программы
энергосбережения
Подсистема
предназначена для
формирования
информационного
пространства топливноэнергетического
комплекса региона,
позволяющего
осуществлять
планирование развития
инженерноэнергетического
комплекса с учетом
территориальных
отраслевых схем
ресурсоснабжения и
Цель
информационного
взаимодействия
Виды
информации
Сбор необходимых
данных и
формирование
отчётности на уровне
муниципальных и
государственных
учреждений,
муниципалитетов,
региона в области
энергосбережения
Отчеты,
справочники,
Организации
Управление
региональным
топливноэнергетическим
хозяйством,
формирование
информационного
пространства
топливноэнергетического
комплекса региона,
позволяющее
осуществлять
планирование
развития инженерно-
Отчеты,
справочники,
графические
данные
25
Возможный способ
взаимодействия
Протокол
взаимодействия:
HTTPS
Формат
взаимодействия:
синхронный API на
базе JSON запросов
Протокол
взаимодействия:
HTTPS
Формат
взаимодействия:
синхронный API на
базе JSON запросов
Наименование ИС
Место
расположения
Краткое описание ИС
генерального плана,
согласование и контроль
за выполнением
инвестиционных
программ, расчета
наиболее эффективного
распределения
энергетических
мощностей
Сервер электронной
почты
Владелец: ГКУ ЛО
«ЦЭПЭ ЛО»
РГИС ЖКХ ЛО
Владелец: Комитет
цифрового развития
Ленинградской
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
Программное
обеспечение для работы
сервера электронной
почты, на который
осуществляется прием
обращений и отправка
уведомлений
ЦОД по адресу:
г. СанктПетербург,
Суворовский
пр., д.67
Региональная
государственная
информационная
система жилищного
хозяйства
Цель
информационного
взаимодействия
энергетического
комплекса с учетом
территориальных
отраслевых схем
ресурсоснабжения и
генерального плана,
согласование и
контроль за
выполнением
инвестиционных
программ, расчета
наиболее
эффективного
распределения
энергетических
мощностей
Получение писем,
рассылка
уведомлений об
изменении состояния
обращений или
информационных
сообщений
Получение данных
по жилищному
фонду.
Виды
информации
Возможный способ
взаимодействия
Входящие письма
для
администраторов,
сотрудников,
обращения
пользователей,
уведомления о
событиях и
задачах
Данные паспортов
МКД
Протокол
взаимодействия:
 получение почты по
протоколам IMAP
или POP3
 отправка почты по
протоколу SMTP.
Протокол
взаимодействия:
HTTPS
Формат
26
Наименование ИС
Место
расположения
области
Краткое описание ИС
Цель
информационного
взаимодействия
Виды
информации
Ленинградской области
Государственный
адресный реестр (ГАР)
Москва,
Походный
проезд, дом 3,
строение 1
Предназначена для
автоматизации работы с
адресами и
обеспечивает их
актуальность и
единообразие
Получение
информации об
адресах
Федеральная
информационная
адресная система
(ФИАС)
Москва,
Походный
проезд, дом 3,
строение 1
Федеральная
государственная
информационная
система,
обеспечивающая
формирование, ведение
и использование
Государственного
адресного реестра
Получение
информации об
адресах
ФГИС «Аршин»
Москва,
Пресненская
наб. д. 10 стр. 2
Специализированная
онлайн платформа,
которая предназначена
для учета и хранения
сведений, касающихся
Получение данных о
сроках поверки
приборов учета
27
Информация о
земельных
участках и
объектах
капитального
строительства,
таких как дома,
квартиры,
владения,
строения и
сооружения
Информация о
земельных
участках и
объектах
капитального
строительства,
таких как дома,
квартиры,
владения,
строения и
сооружения
Название модели
прибора учета
Тип модели
Серийный номер
Ресурс
Возможный способ
взаимодействия
взаимодействия:
синхронный API на
базе JSON запросов
Открытые данные
(файловые
выгрузки/транспортные
файлы)
Открытые данные
(файловые
выгрузки/транспортные
файлы)
Открытые данные
(файловые
выгрузки/транспортные
файлы
Наименование ИС
Место
расположения
Краткое описание ИС
Цель
информационного
взаимодействия
результатов поверки
средств измерений,
включая приборы
коммерческого учета
Виды
информации
Условный
диаметр
Дата установки
Дата начала
поверки
Дата окончания
поверки
Номер документа
28
Возможный способ
взаимодействия
5.1.4
Требования по применению систем управления базами данных
Для контроля и хранения данных должна использоваться СУБД из реестра,
включенных в реестр российского ПО или допущенная к использованию
программными продуктами, включенными в реестр.
СУБД должна обеспечивать транзакционные механизмы, декларативную
ссылочную целостность, а также позволять наращивать производительность всего
комплекса путем увеличения мощностей технических средств без изменений на
прикладном уровне.
СУБД должна использоваться всеми модулями Подсистемы. Все данные,
кроме электронных образов документов, изображений и журналов событий
должны храниться в СУБД.
5.1.5
Требования к представлению данных в подсистеме
Дополнительные требования к представлению данных в Подсистеме не
предъявляются.
5.1.6
Требования к контролю, хранению, обновлению
и восстановлению данных
Для хранения файлов и иных бинарных данных должна использоваться
горизонтально масштабируемая система хранения данных, не ниже уровня
RAID10.
Для обеспечения возможности восстановления данных в случае их
ошибочного изменения и ведения журнала изменений данных в поставляемой
системе должен быть обеспечен механизм версионности данных.
В случае использования внешних по отношению к СУБД инструментов для
контроля, хранения и восстановления данных, должны использоваться решения с
открытым исходным кодом или импортозамещённые решения.
29
5.2
Требования к лингвистическому обеспечению Подсистемы
5.2.1
Требования к языкам, используемым в Подсистеме
Лингвистическое обеспечение Подсистемы должно быть рассчитано на
пользователя, специалиста в предметной области, не владеющего универсальными
языками программирования или описаниями алгоритмов.
Пользовательский интерфейс должен быть локализован для Российской
Федерации. Вся текстовая информация должна быть представлена на русском
языке.
Возможность расширения состава используемых языков – не требуется.
5.2.2
Требования к способам организации диалога
Взаимодействие пользователей с Подсистемой должно осуществляться
посредством
визуального
графического
интерфейса,
который
проходит
утверждение у заказчика в виде макета после его подготовки.
Все необратимые действия должны осуществляться с использованием
дополнительных диалогов подтверждения.
5.2.3
Требования к разработке и использованию словарей, тезаурусов
Не предъявляются.
5.2.4
Требования к описанию синтаксиса формализованного языка
Не предъявляются.
5.3
Требования к программному обеспечению Подсистемы
5.3.1
Требования к составу и видам программного обеспечения
Используемое при разработке программное обеспечение и библиотеки
программных
кодов
должны
иметь
широкое
распространение,
общедоступными и использоваться в промышленных масштабах.
30
быть
5.3.2
Требования к выбору используемого программного обеспечения
Используемое в составе Подсистемы программное обеспечение и языки
программирования должны подходить для последующей регистрации Подсистемы
в Реестре российского программного обеспечения.
Для
программного
обеспечения
клиентской
части
Подсистемы
предъявляются следующие требования:
 работа в операционных системах, включенных в Единый реестр
российских программ для электронных вычислительных машин и баз
данных;
 использование интернет-браузера, включенного в Единый реестр
российских программ для электронных вычислительных машин и баз
данных, совместимого с соответствующей операционной системой.
Для
программного
обеспечения
серверной
части
Подсистемы
предъявляются следующие требования:
 функционирование в серверных системах, включенных в Единый реестр
российских программ для электронных вычислительных машин и баз
данных;
 использование языков и библиотек, допустимых для использования в
программах, которые будут включены в Единый реестр российских
программ для электронных вычислительных машин и баз данных;
 функционирование на СУБД, включенной в Единый реестр российских
программ для электронных вычислительных машин и баз данных.
5.3.3
Требования к разрабатываемому программному обеспечению
Система должна быть рассчитана на использование браузеров с поддержкой
HTML 5.0, CSS Level 3, JQuery 3.6, режима асинхронного взаимодействия
JavaScript/XML (XML, HTTP, Request и т.п.).
Пользовательские
интерфейсы
должны
быть
протестированы
совместимость с браузером Яндекс.Браузер версии 24.6.3 и выше.
31
на
5.3.4
Требования к покупным программным средствам
В Подсистеме должны быть использованы только те сторонние
компоненты, которые могут быть приобретены (получены) и используются без
нарушений лицензионных соглашений, доступны к приобретению на территории
Российской Федерации, с учетом рекомендаций по импортозамещению.
5.4
Требования к техническому обеспечению
В разделе представлены общие требования к техническому и программному
обеспечению, на котором будет функционировать Подсистема.
Окончательный состав серверного и сетевого оборудования, систем
хранения данных определяется на этапе проектирования.
5.4.1
5.4.1.1
Требования к системно-технической инфраструктуре
Требования к локальным вычислительным сетям
Серверы БД, приложений, прикладного ПО и файловый сервер должны
быть объединены одной локальной сетью с пропускной способностью 1 Гбит/сек.
Пропускная способность канала передачи данных от Web-сервера и
файлового сервера до рабочих мест пользователей должна быть организована
защищенным каналом связи с пропускной способностью не менее 3 Мбит/сек на
пользователя.
Защита каналов связи должна обеспечиваться сертифицированными
средствами защиты.
5.4.1.2
Требования к вычислительным комплексам
Сервера должны быть размещены в дата-центре, обеспечивающем:
 несколько скоростных подключений к сети Интернет;
 круглосуточную гарантированную физическую защиту периметра от
доступа посторонних;
 наличие систем автономного кондиционирования;
 две независимые системы электропитания, включая резервные;
 наличие системы пожаротушения.
32
Для
размещения
Подсистемы
должны
использоваться
аппаратно-
программные средства с поддержкой работы виртуальных машин и механизмов
контейнеризации.
Для обеспечения стабильной работы аппаратной составляющей системы
должны быть предусмотрены инструменты для мониторинга и управления всеми
компонентами инфраструктуры, включая серверы, сети, хранилища данных и
приложения.
5.4.1.3
Требования к системам хранения данных
К системам хранения данных, на которых будет размещаться Подсистема
предъявляются следующие требования:
 система хранения построена на SSD или SSD M.2 уровня не ниже
RAID10;
 технические решения должны быть основаны на базе серийно
выпускаемых программных, аппаратных или программно-аппаратных
средств, срок технической поддержки которых заканчивается не ранее
чем через 3 года с момента ввода Подсистемы в эксплуатацию.
5.4.2
Требования к автоматизированным рабочим местам
В
качестве
пользовательского
оборудования
Заказчиком
должны
использоваться средства вычислительной техники, обеспечивающие работу
следующего программного обеспечения:
 операционной системы РЕД ОС 7.3 «Рабочая станция»;
 браузера Яндекс. Браузер версии 24.6.3 и выше.
5.4.3
Требования к функциональным группам серверов
Для
выполнения
показателей
надежности
и
отказоустойчивости
Подсистемы в технические требования к Подсистеме должны быть заложены узлы
для балансировки нагрузки и создания отказоустойчивых кластеров на уровне вебсервера и сервера баз данных.
33
5.5
Требования к метрологическому обеспечению
Дополнительные
требования
к
метрологическому
обеспечению
не
предъявляются.
5.6
Требования к организационному обеспечению
Для обеспечения качественной и непрерывной работы Подсистемы
Исполнитель должен руководствоваться требованиями к порядку организации
работы при сбоях и нештатных ситуациях.
5.6.1
Требования к порядку организации работы при сбоях и нештатных
ситуациях
При
возникновении
сбоев
или
нештатных
ситуаций
в
работе
информационной Подсистемы или ее инфраструктуры должна быть обеспечена
следующая последовательность действий сотрудников Заказчика с целью
минимизации последствий и времени простоя:
 Выявление проблемы:
 Пользователи или автоматические системы мониторинга сообщают
о проблеме;
 Служба поддержки фиксирует инцидент, классифицирует его по
приоритету и категории;
 При невозможности оперативного решения инцидента на текущем
уровне компетенции, инцидент должен быть передан на следующий
уровень технической поддержки или ответственному руководителю
для скорейшего решения инцидента;
 При более масштабных инцидентах разрабатывается специальный
план для более быстрого реагирования на инциденты;
 Все действия по инциденту должны фиксироваться с временными
метками: (кто, когда и что предпринял) – последующего анализа и
отчетности;
34
 По завершении инцидента(ов) проводится всесторонний анализ
целостности и работоспособности компонентов Подсистемы и её баз
данных
для
последующего
определения
ущерба,
причинённого
инцидентом(и). После выявления последствий разрабатываются и
реализуются меры по их устранению, а также по предотвращению
аналогичных ситуаций в будущем. При этом проводится оценка
остаточного риска, связанного с выявленными уязвимостями или
последствиями, и при необходимости принимаются компенсирующие
меры по его снижению до приемлемого уровня.
 Анализ и диагностика инцидента:
 Специалисты проводят анализ ситуации, чтобы определить причину
сбоя;
 При необходимости привлекаются разработчики, администраторы
систем или специалисты по безопасности;
 Производится
оценка
возможности
устранения
инцидента,
необходимые ресурсы и сроки выполнения работ.
 Устранение проблемы:
 Если проблема связана с оборудованием, принимаются меры по
восстановлению работоспособности оборудования, сервера или сети;
 В случае программного сбоя проводится перезапуск служб, изменение
настроек системы и прикладного ПО, в случае необходимости,
производится исправление кода Подсистемы;
 Для оперативного восстановления работоспособности Подсистемы
могут применяться временные обходные решения.
 Оценка последствий и восстановление после сбоев:
 После устранения проблемы оценивается влияние инцидента на бизнеспроцессы;
 Для критичных инцидентов принимаются меры по предотвращению
инцидентов в процессе дальнейшей эксплуатации;
35
 Проводится
проверка
корректности
восстановления
данных
и
обеспечению
не
функционирования Подсистемы.
5.7
Требования к методическому обеспечению
Дополнительные
требования
к
методическому
предъявляются.
36
6
ОБЩИЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ПОДСИСТЕМЕ
6.1
Требования к надежности Подсистемы
 Должно быть предусмотрено сохранение работоспособности Сервисов
(алгоритмов обеспечивающих функционирование бизнес-процессов
Подсистемы) при некорректных действиях пользователя и сохранение
целостности данных при нештатном завершении работы Сервиса (отказ
рабочей станции, потеря сетевого доступа и т.п.);
 В Подсистеме должен быть реализован контроль версий компонентов,
обеспечивающий возможность отката к предыдущим стабильным
версиям в случае сбоев после обновлений;
 Сервисы должны иметь средства обеспечения отказоустойчивости
(например, средства репликации и резервирование вычислительных
узлов);
 Сервисы должны предоставлять механизмы обеспечения сохранности
данных через применение процедур резервного копирования и
восстановления, описанных в документации Сервиса;
 Архитектура
Подсистемы
должна
соответствовать
требованиям
действующего законодательства РФ в области информационной
безопасности;
 Автоматическое восстановление сервисов при сбоях без вмешательства
пользователя;
 Проведение регулярных тестов на устойчивость к сбоям и проверок
корректности восстановления данных;
 Реализация журналирования критических событий с возможностью их
централизованного анализа;
 Реализация защиты от перегрузки, включая ограничение частоты
запросов и блокировку потенциально опасной активности;
 Обеспечение работы Подсистемы при кратковременном отсутствии
сетевого соединения за счет локального кэширования с последующей
синхронизацией данных;
37
 Ведение дублирующих логов и копий конфигурационных файлов в
защищенном хранилище;
 Исполнитель должен периодически проводить тестирование сценариев
отказа (в том числе моделирование отказа сетевого взаимодействия,
остановки узлов и пр.) с целью проверки работоспособности механизмов
отказоустойчивости и готовности к нештатным ситуациям;
 Все обновления Сервиса должны производиться с соблюдением
процедур
безопасного
развертывания
—
без
прерывания
предоставления услуг или с минимальными допустимыми перерывами,
заранее согласованными с Заказчиком.
6.2
Требования по конфиденциальности
Подсистема находится на серверах Заказчика. Исполнитель осуществляет
развитие Подсистемы в соответствии с действующими регламентами Заказчика.
Выполняемые работы должны удовлетворять требованиям качества и
безопасности в соответствии с действующим законодательством Российской
Федерации, Ленинградской области, а также удовлетворять техническим
требованиям, представленным в настоящем ООЗ (техническом задании).
Качество выполненных работ должно обеспечиваться в соответствии с
требованиями статьи 721 Гражданского кодекса Российской Федерации.
Работы должны быть оказаны в срок, в полном объеме и с надлежащим
качеством в соответствии с требованиями настоящего Описания объекта закупки и
государственного контракта.
Исполнитель не имеет права передавать третьим лицам информацию,
полученную в процессе выполнения работ, и сведения о характере выполняемых
работах, а также обеспечить конфиденциальность и безопасность этой информации
в соответствии с требованиями действующего законодательства Российской
Федерации.
38
Обработка и хранение информации ограниченного доступа должны
производиться
в
соответствии
с
действующим
законодательством
и
организационно-распорядительными документами Заказчика.
Работы не должны приводить к потере информации, ранее размещенной в
Подсистеме, или потере доступных ранее функциональных возможностей.
Исполнитель обязан выполнять работы с соблюдением действующих
правил и норм техники безопасности, пожарной безопасности, а также иных
утвержденных
и
зарегистрированных
в
установленном
порядке
актов
уполномоченных органов государственной власти в сфере охраны труда.
Защита Подсистемы от несанкционированного доступа обеспечивается:
 аутентификацией пользователей по паролю условно-постоянного
действия;
 функциями регистрации входа/выхода пользователя в/из системы и
попытки неудачного входа в систему (для блокирования попыток
подбора паролей);
 организацией доступа к данным и функциям Подсистемы на основании
разработанной ролевой модели Подсистемы;
 автоматическим завершением сеанса пользователя после определенного
периода бездействия;
 обеспечением безопасности при внедрении обновлений: обязательное
тестирование новых версий на предмет соответствия требованиям ИБ
Заказчика;
 проведением
регулярных
проверок
Подсистемы
на
наличие
уязвимостей.
Соблюдать методические рекомендаций по защите информации и контролю
действий пользователей, утверждённых ФСТЭК России.
6.3
Требования к эргономике и технической эстетике
При
отображении
числовых
данных
должны
быть
использованы
разделители разрядов. При отображении финансовой информации должно
39
использоваться выравнивание данных по правому краю блока и разделители
разрядов.
Все элементы управления, выполняющие одинаковые функции, называются
одинаково.
Поля, ввод информации в которые является обязательным, специально
отмечены для того, чтобы визуально отличаться от полей, заполнение которых
обязательным не является.
Подсистема предусматривает возможность использования справочников
при работе с полями ввода информации.
Допускается более долгое отображение экранных форм в разделах,
связанных с архивными данными.
При обнаружении Подсистемой ввода некорректных данных, информация в
корректно заполненных полях сохраняется, при этом пользователю предлагается
повторить ввод только данных, не прошедших проверку.
Дизайн интерфейса Подсистемы удовлетворяет следующим требованиям по
эргономике и технической эстетике:
 корректно
отображается
при
стандартных
разрешениях
экрана
(1920х1080 и выше) и количестве одновременно отображаемых цветов
монитора (от глубины цвета 16 bit);
 обладает системой контекстных подсказок на страницах, где у
пользователя потенциально могут возникнуть затруднения;
 адаптирован для восприятия интерфейса на различных браузерах
(кроссбраузерность);
 использовать единый стиль элементов управления, цветовой схемы,
типографии и пиктограмм во всей Подсистеме;
 гарантирует читаемость текста за счет достаточного контраста шрифта и
фона;
 содержит механизмы визуальной обратной связи (подсветка активных
элементов, на одной странице);
40
 поддерживается
единая
логика
навигации
по
Подсистеме,
обеспечивающая быстрое перемещение между основными разделами;
 предусмотрена защита от непреднамеренных действий пользователя
(подтверждение
при
удалении,
предупреждения
при
потере
несохраненных данных).
Требования к эргономике рабочих мест не предъявляются.
6.4
Требования к эксплуатации, техническому обслуживанию, ремонту и
хранению компонентов Подсистемы
Подсистема
рассчитана
на
эксплуатацию
в
составе
программно–
технического комплекса Заказчика и учитывать разделение ИТ инфраструктуры
Заказчика на внутреннюю и внешнюю.
Для эксплуатации Подсистемы должно быть обеспечено бесперебойное
питание серверов. При эксплуатации Подсистема должна быть обеспечена
соответствующая стандартам хранения носителей и эксплуатации температура и
влажность воздуха.
Периодическое техническое обслуживание используемых технических
средств должно проводиться в соответствии с требованиями технической
документации изготовителей, но не реже одного раза в год.
Эксплуатация технических средств Подсистемы должна производиться
специалистами Заказчика или уполномоченными подрядчиками с учетом
выполнения
требований
производителей
оборудования,
выполнением
периодического обслуживания и регламентных работ в рамках функционирования
службы эксплуатации ИС.
Обслуживание
технических
компонентов
Подсистемы
должно
производиться специализированным подразделением – службой эксплуатации ИС
или аналогичным, обладающим достаточной квалификацией.
Дополнительных требований к хранению компонентов Подсистемы не
предъявляется.
41
6.5
Требования к сохранности информации при авариях
Для
обеспечения
сохранности
информации
при
авариях
СУБД,
используемая в составе Подсистемы должна обеспечивать транзанкционность
записи данных для обеспечения их сохранности при авариях.
Перечень аварийных ситуаций, при которых должна быть обеспечена
сохранность информации:
 при сбоях в системе электроснабжения аппаратной части, приводящих к
перезагрузке ОС;
 при ошибках в работе аппаратных средств сервера приложений (кроме
носителей данных и программ);
 при сбоях сетевого оборудования и ошибках каналов связи между
сервером приложений и пользовательскими рабочими местами;
 при отказе сетевого оборудования;
 при сбоях в работе систем резервного копирования или восстановления
из резервной копии;
 при ошибках или некорректной работе программного обеспечения
серверной части Подсистемы (в том числе приложений, драйверов и
СУБД);
 при возникновении программных «зависаний» или утечек памяти в
процессе выполнения транзакций;
 при сбоях в работе OC сервера, включая критические ошибки ядра или
зависание системы;
 при ошибках или некорректных действиях администратора, ведущих к
незавершённым транзакциям или сбоям в логике работы;
 при сбоях в системах виртуализации или контейнеризации, если
Подсистема развёрнута в виртуальной среде;
 при ошибках при применении обновлений СУБД или миграции схемы
базы данных.
42
Для обеспечения непрерывного функционирования Подсистемы, в рамках
сопровождения,
организованы
мероприятия
по
резервированию
данных,
внесенных пользователями в Подсистему.
Для исключения потерь или порчи данных при отказе сетевого
оборудования должны использоваться транзакционные механизмы на уровне
СУБД.
6.6
Требования к защите от влияния внешних воздействий
Защита от влияния внешних воздействий должна обеспечиваться
средствами технического комплекса ЦОД Правительства Ленинградской области.
Для программных средств требования не предъявляются.
6.7
Требования к патентной чистоте и патентоспособности
Патентная чистота Подсистемы должна быть обеспечена в отношении
патентов,
действующих
на
территории
Российской
Федерации,
должны
соблюдаться положения законодательных актов Российской Федерации по
соблюдению авторских прав и защите специальных знаков.
Реализация технических, программных, организационных и иных решений
не должна приводить к нарушению авторских и смежных прав третьих лиц.
Исполнитель обязан обеспечить передачу Заказчику полученных по Контракту
результатов работ, не нарушающих исключительных прав других лиц и не
являющихся предметом залога, ареста или иного обременения.
В случае использования при выполнении работ по Контракту программ для
электронных
вычислительных
машин
(программных
комплексов
или
компонентов), разработанных третьими лицами, условия, на которых передаются
права на их использование (исполнение), должны обеспечить отсутствие
ограничений,
препятствующих
использованию
результатов
работ
по
их
назначению. При этом права, полученные Заказчиком, должны позволять ему
передавать, дорабатывать, развивать результаты работ, созданные в процессе
исполнения Контракта, а в случае явного указания в Техническом задании,
43
осуществлять переработку программ для электронных вычислительных машин
(программных комплексов или компонентов), разработанных ранее третьими
лицами в соответствии с требованиями законодательства Российской Федерации.
Исключительные права на результаты интеллектуальной деятельности, в
том числе, но не исключая: изобретения, полезные модели, промышленные
образцы, программы для электронных вычислительных машин, базы данных,
топологии интегральных микросхем, а также исключительные права на результаты
работ, включая объекты авторских прав и потенциально патентоспособные
технические решения, секреты производства (ноу-хау), созданные в рамках
Контракта, принадлежат субъекту Российской Федерации Ленинградской области,
от имени которого выступает Заказчик. Право собственности на результаты работ,
отчетные документы и материалы, полученные в ходе выполнения работ по
Контракту, принадлежат субъекту Российской Федерации Ленинградской области,
от имени которого выступает Заказчик и считаются переданными с момента
подписания Сторонами документа о приемке (технического акта) выполненных
работ.
В случае использования компонентов, распространяемых по открытым
лицензиям, Исполнитель обязан указать используемую лицензию и обеспечить,
чтобы её условия не препятствовали правомерному использованию, доработке и
распространению результатов работ.
Исключительные права на все результаты интеллектуальной деятельности,
созданные в рамках исполнения Контракта, включая объекты авторского права и
патентоспособные технические решения, полностью и безвозвратно передаются
Заказчику с момента подписания акта приёмки выполненных работ.
Исполнитель
несёт
полную
ответственность
за
правомерность
использования всех программных компонентов и технических решений,
применённых в рамках Контракта, включая обязательства по возмещению убытков
Заказчику в случае предъявления претензий со стороны третьих лиц.
44
7
СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ ПОДСИСТЕМЫ
7.1
Требования к безопасности выполнения работ
Информация, ставшая доступной сторонам в процессе выполнения работ по
Контракту, является информацией ограниченного доступа, в том числе к ней
относится:
 информация о Контракте и о результатах выполненных работ по нему;
 информация о технических и программных возможностях Сторон;
 информация о кредитно-финансовом положении Сторон;
 информация о документообороте Сторон;
 информация о методах и средствах защиты информации;
 информация о внутренних бизнес-процессах;
 исходные коды, скрипты, модули, используемые в процессе разработки;
 данные журналов регистрации событий, действий пользователей и
администраторов;
 информация о системах мониторинга, резервного копирования и
восстановления.
7.2
Требования к сроку и объему предоставления гарантий качества работ
Гарантийный срок на результаты выполненных Работ составляет 12
(двенадцать) месяцев от даты подписания Заказчиком документа о приемке в ЕИС по
последнему этапу исполнения Контракта.
Гарантийные
обязательства
Исполнителя
распространяются
на
все
программные и технические компоненты Подсистемы, включая интеграции с
внешними системами, разработанные или доработанные в рамках исполнения
Контракта.
В случае выявления ошибок, недостатков, а также отклонений от требований
настоящего технического задания, Исполнитель безвозмездно устраняет их в течение
гарантийного срока.
45
При повторном возникновении аналогичной ошибки в течение гарантийного
срока Исполнитель обязан провести комплексный анализ причин и реализовать
мероприятия по предотвращению подобных инцидентов в будущем.
Срок устранения выявленных в ходе эксплуатации ошибок и недостатков, а
также отклонений от требований настоящего технического задания, не более 10
(десяти) рабочих дней с момента получения сообщения от Заказчика о недостатках в
работе Подсистемы.
Устранение ошибок и недостатков должно сопровождаться предоставлением
Исполнителем отчета с указанием причин неисправности, предпринятых действий и
подтверждением восстановления работоспособности Подсистемы в полном объеме.
Гарантийный
срок
исчисляется
с
даты
подписания
акта
приёмки
соответствующего этапа работ, а при наличии замечаний — с момента подписания
акта об устранении всех выявленных недостатков.
7.3
Требования к объему работ
Техническая и эксплуатационная документация на Подсистему должны
удовлетворять требованиям комплекса стандартов и руководящих документов на
автоматизированные системы:
 ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Виды испытаний автоматизированных
систем»;
 ГОСТ Р 59853-2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Термины и
определения»;
 ГОСТ Р 2.105-2019 «Национальный стандарт Российской Федерации.
Единая система конструкторской документации. Общие требования к
текстовым документам»;
46
 ГОСТ Р 2.106-2019 «Национальный стандарт Российской Федерации.
Единая система конструкторской документации. Текстовые документы»;
 ГОСТ 34.201-2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы. Виды,
комплектность
и
обозначение
документов
при
создании
автоматизированных систем»;
 ГОСТ 34.602-2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы».
Подсистема должна удовлетворять ГОСТ Р 52872-2019 «Национальный
стандарт Российской Федерации. Интернет-ресурсы и другая информация,
представленная в электронно-цифровой форме. Приложения для стационарных и
мобильных устройств, иные пользовательские интерфейсы. Требования доступности
для людей с инвалидностью и других лиц с ограничениями жизнедеятельности».
47
8
ПОРЯДОК РАЗВИТИЯ АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЫ
8.1
Порядок развития Подсистемы
Состав и содержание работ по развитию функциональных возможностей
Подсистемы указаны в таблице 8.1.
Таблица №8.1 – Работы по развитию Подсистемы
№
п/п
Наименование работ
1.
Разработка функциональной
возможности выбора периода
графика и реестра в
функциональном модуле «Контроль
превышения фактического
теплопотребления от проектного»
раздела «Энергоэффективность»
2.
Разработка функциональной
возможности выбора периода в
модуле «Контроль температурного
графика» раздела
«Энергоэффективность»
3.
Разработка функции «печатная
форма» по разделу «Контроль
температурного графика» из дерева
объектов по выбранному ресурсу
«Теплоснабжение» выбранного
объекта в разделе
4.
Доработка модуля «Реестры» в
разделе формирования отчетности
«Сверхнормативное потребление
тепловой энергии», в части
доработки выбора района при
формировании отчета.
5.
Разработка экранной формы
«Контроль температурного
графика» по коммунальной услуге
Детализация
Реализовать отображение данных за период для
раздела График
Реализовать отображение данных за период для
раздела Карта
Реализовать отображение данных за период для
раздела Реестр
Реализовать печатную форму графика и реестра по
выбранному периоду
Итоговое тестирование
Реализовать отображение данных за период для
раздела График
Реализовать отображение данных за период для
раздела Карта
Создание раздела реестра с отображением
выбранного периода
Реализовать печатную форму отчета в разделе
реестр за выбранный период
Итоговое тестирование
Разработка печатной формы «Контроль
температурного графика» по объекту потребления
в разделе КТГ
Добавить возможность формировать отчет по
выбранному периоду «Контроль температурного
графика» из дерева объектов
Добавление в отчет функции нарушения и
отклонения подачи теплоносителя
Итоговое тестирование
В модуле «Реестры» в функции отчетности
«Сверхнормативное потребление тепловой
энергии» расширить возможности и функционал
возможностью выбора района
Запретить выбирать головной прибор, если не
указан объект головного прибора
Итоговое тестирование
Разработка механизмов подбора данных
(котельные, РСО, тип зданий)
Разработка экранной формы для отображения
48
№
Наименование работ
п/п
на уровне объекта потребления
6.
Добавление механизмов расчета
рекомендуемого расхода для
температурных графиков на уровне
объекта потребления, прибор
объекта
Детализация
информации о нарушениях температурного
графика в виде диаграммы или графика
Итоговое тестирование
Разработка функции расчета рекомендуемого
расхода для по температурному графику на
обратном трубопроводе в разделе КТГ прибора
объекта.
Разработка печатной формы для рекомендуемого
расчета по объекту.
Итоговое тестирование
7.
8.
9.
Разработка интерактивного виджета
на стартовой странице с
функциональной информацией по
перерасходу тепловой энергии от
нормативного показателя в
денежном выражении
Доработка формирования отчета в
модуле «Реестры», раздел
«Превышение лимитов
потребления» в части выбора района
без привязки к подключенным
объектам
Миграция (перенос) данных и
объектов схемы данных из текущей
СУБД PostgreSQL в целевую СУБД
Postgres Pro
Разработка механизма расчета
Обеспечено штатное функционирование виджета
на стартовой странице
Итоговое тестирование
Добавлено поле выбора района в разделе
формирования отчета по «Превышению лимитов
потребления»
Итоговое тестирование
Разработка плана миграции с определением
последовательности переноса объектов и оценкой
трудоемкости. Перенос и адаптация хранимых
процедур, функций, триггеров и других
программных объектов с учетом особенностей
Postgres Pro
Итоговое тестирование
8.2
Разработка функциональной возможности выбора периода графика и
реестра в функциональном модуле «Контроль превышения фактического
теплопотребления от проектного» раздела «Энергоэффективность»
Для обеспечения ретроспективного анализа данных системы в разрезе
объектов
и
функционала
периодов
«Контроль
требуется
реализовать
превышения
возможность
фактического
проектного» в разрезе периодов.
49
формирования
теплопотребления
от
Функционал может быть реализован путем добавления и переработки
существующей формы или путем добавления отдельного подраздела в разделе
«Энергоэффективность».
За
основу
функционала
должны
браться
данные
из
раздела
«Теплоснабжение», отображающего на уровне ресурса «Теплоснабжение» по
отдельному объекту.
Выбор адресов осуществляется в дереве объектов в левой части экранной
формы путем выбора уровня адресного плана: муниципальное образование, город,
улица, конкретный дом.
Выбор периода осуществляется при помощи специализированного поля ввода
дат. Ввод периода должен быть ограничен 6 месяцами в цели оптимизации времени
расчетов.
8.2.1
Реализовать отображение данных за период «с, по» для раздела
«График»
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «График», которой позволяет визуально сравнить между
отклонение в потреблении объектов от эталонных значений.
Для сравнения объектов должна быть реализована механика цветового
кодирования по выбранному периоду.
8.2.2
Реализовать отображение данных за период для раздела Карта
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «Карта», которой позволяет визуально выявить, где наибольшее
отклонение в потреблении объектов от эталонных значений.
Для сравнения объектов должна быть реализована механика цветового
кодирования и выбора периода.
8.2.3
Реализовать отображение данных за период для раздела Реестр
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «Реестр», которой позволяет сравнить между отклонение в
потреблении объектов от эталонных значений в числовом эквиваленте.
50
8.2.4
Реализовать печатную форму отчета
Для контроля результатов анализа требуется реализовать печатную форму с
собранной информацией по выбранному периоду и адресным объектам.
Предварительный состав информации:
 Дата и время формирования отчета;
 Период формирования отчетности;
 Пользователь, сформировавший отчет;
 Количество объектов, использованных для отчета;
 Табличная часть:
 Адрес объекта;
 Фактическое значение;
 Паспортное значение;
 Объем превышения паспортного значения в большую сторону (%);
 Объем превышения паспортного значения в большую сторону в
рублях.
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.3
Разработка функциональной возможности выбора периода в модуле
«Контроль температурного графика» раздела «Энергоэффективность»
Для обеспечения ретроспективного анализа данных системы в разрезе
объектов
и
периодов
требуется
реализовать
возможность
формирования
функционала «Контроль температурного графика» в разрезе периодов.
Функционал может быть реализован путем добавления и переработки
существующей формы или путем добавления отдельного подраздела в разделе
«Энергоэффективность».
За основу функционала должны браться данные, заведенного в систему
температурного графика и данные фактически поставленных на объект ресурсов.
51
Выбор адресов осуществляется в дереве объектов в левой части экранной
формы.
Выбор периода осуществляется при помощи специализированного поля ввода
дат. Ввод периода должен быть ограничен 6 месяцами в цели оптимизации времени
расчетов.
8.3.1
Реализовать отображение данных за период для раздела График
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «График», которой позволяет визуально сравнить между
отклонение в поставке ресурсов на объекты от эталонных значений температурного
графика по выбранному периоду.
График должен отображать цветом объекты, в которых количество дней с
отклонением превышает установленные в Системе значения.
Правила подбора внутри дня:
 Зеленое: отклонение в среднем за сутки до 3%;
 Желтое: отклонения в среднем за сутки выше 3%;
 Красная: отклонения в среднем за сутки выше 30% в отрицательную
сторону (дом остывает) при отрицательной температуре наружного
воздуха.
8.3.2
Реализовать отображение данных за период для раздела Карта
Для визуального сравнения объектов между собой должен быть реализован
режим просмотра «Карта», которой позволяет визуально выявить, где наибольшее
отклонение в температурных режимах от эталонных значений.
Для сравнения объектов должна быть реализована механика цветового
кодирования, описанная в правилах отображения графиков.
8.3.3
Реализовать отображение данных за период для раздела Реестр
Для визуального сравнения объектов между собой должен быть реализован
режим
просмотра
«Реестр»,
которой
позволяет
сравнить
количественные показатели отклонений от температурного графика.
52
между
собой
8.3.4
Реализовать печатную форму отчета
Для контроля результатов анализа требуется реализовать печатную форму с
собранной информацией по выбранному периоду и адресным объектам.
Предварительный состав информации:
 Дата и время формирования отчета;
 Пользователь, сформировавший отчет;
 Количество объектов, использованных для отчета;
 Табличная часть:
 Адрес объекта;
 Используемый график (название);
 Ресурсоснабжающая организация;
 Подача:

Среднее значение температуры на подаче;

Минимальное отклонение в натуральных показателях и %;

Дата минимального отклонения;

Температура наружного воздуха при минимуме;

Максимальное отклонение в натуральных показателях и %;

Дата максимального отклонения параметра;

Температура наружного воздуха при максимуме;
 Обратная труба:

Среднее значение температуры на обратной трубе;

Минимальное отклонение в натуральных показателях и %;

Дата минимального отклонения;

Температура наружного воздуха при минимуме;

Максимальное отклонение в натуральных показателях и %;

Дата максимального отклонения параметра;

Температура наружного воздуха при максимуме.
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
53
задании или в дополнительном соглашении, требования к содержанию и
отображаемым показателям экранной форм "Контроль температурного графика"
должны соответствовать Приказу Министерства энергетики РФ от 5 марта 2019 г. №
212 "Об утверждении Методических указаний по разработке схем теплоснабжения".
8.4
Разработка печатной формы «Контроль температурного графика» по
объекту потребления
Для передачи организациям, ответственным за обслуживание и эксплуатацию
объектов, а также организациям – поставщикам коммунальных ресурсов необходимо
реализовать
печатную
форму,
детализирующую
проблемы
с
соблюдением
температурного графика в разрезе конкретного объекта.
8.4.1
Реализовать возможность формировать отчет по конкретному объекту
Форма должна быть доступна из раздела «Отчеты» на уровне «Объект»
В печатной форме должно быть отображено:
 Входные параметры отчета: фильтры, даты, автор;
 Адрес объекта;
 Управляющая и владеющая организация;
 Ресурсоснабжающая организация;
 Наименование температурного графика;
 Вид контроля: по подаче / по обратному трубопроводу;
 Табличная часть:
 Дата фиксации;
 Температура наружного воздуха;
 Значение по температурному графику;
 Фактическое значение;
 Процент отклонения;
 Результирующая часть:
 Количество дней с отклонением до 3%;
 Количество дней с отклонением от 3% до 30%;
 Количество дней с отклонением более 30%.
54
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.4.2
Добавить возможность формировать отчет «Контроль температурного
графика» из дерева объектов
Необходимо
добавить
возможность
сформировать
отчет
«Контроль
температурного графика» с основной страницы «Дерево объектов» по объектам,
выбранным «галочкой» в адресном плане.
8.5
Доработка модуля «Реестры» в разделе формирования отчетности
«Сверхнормативное потребление тепловой энергии», в части доработки
выбора района при формировании отчета.
8.5.1
Добавить возможность выбора района
В модуле «Реестры» в функции отчетности «Сверхнормативное потребление
тепловой энергии» добавить возможность ограничить муниципальное образование
при формировании отчета.
Для пользователей с ролью «Система. Администратор» должны подбираться
все объекты в МО. Для прочих пользователей должны подбираться все объекты в МО,
к которым организация пользователя имеет доступ на основании привязок.
Одновременно может быть задан либо фильтр по муниципальному
образованию, либо по головному объекту (котельной).
Добавить фильтр по организации - поставщику коммунального ресурса.
Добавить фильтр по организации, отвечающей за эксплуатацию объекта:
подбирается по привязкам «Управление», «Владение», «Представление интересов
собственника».
Добавить фильтр по полю «Обслуживающая организация».
55
8.5.2
Запретить выбирать головной прибор, если не указан объект головного
прибора
Добавить обработку, которая будет блокировать выбор головного прибора,
если не указан головной объект.
8.6
Добавление
механизмов
расчета
рекомендуемого
расхода
для
температурных графиков
Для обеспечения контроля потребления и циркуляции внутри объекта
необходимо реализовать механизмы контроля и печатную форму, которая будет
отображать рекомендации по настройке циркуляции внутри объекта потребления.
Работа механизма контроля строится на основе температурного графика и
фактических значений потребления за период.
8.6.1
Разработка функции расчета рекомендуемого расхода для
температурного графика на обратном трубопроводе
Для
создания
возможности
контролировать
качество
циркуляции
теплоносителя внутри объектов и внесения корректировок в температурные графики
с целью оказания более качественных услуг, требуется изменить механизм
срабатывания уставки КЦ на уровне просмотра показаний прибора учета на обратной
трубе на следующую формулу:
М2рек=Qo*1000/(h(tгпрям;Рпрям)-h(tгобр;Робр))
Итоговое значение округляем в большую сторону до целого.
Изменить отображаемый текст уставки КЦ на следующий:
«Рекомендуемый расход получился меньше и его надо снизить до 52 т/ч.»
Новое уведомление должно выводиться в столбце «Предупреждение» во
вкладке «Архивные показания» на уровне «Прибор учета» вместо прежнего
сообщения.
8.6.2
Разработка печатной формы для рекомендуемого расхода по объекту
Разработать печатную форму, отображающую данные уставки КЦ и
рекомендации. Форма должна быть доступа с уровня.
56
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.7
Разработка
интерактивного
виджета
на
стартовой
странице
с
функциональной информацией по перерасходу тепловой энергии от
нормативного показателя в денежном выражении
На
стартовой
странице
системы
должен
быть
реализован
виджет
«Интегральный рейтинг энергоэффективности по тепловой энергии» в виде шкалы
(светофора), который отображает информацию об объеме перерасходуемой тепловой
энергии по всем объектам пользователя.
За основу расчета берется механизм расчета из раздела «Теплопотребление»
на уровне конкретного объекта.
Виджет доступен пользователям, привязанным к организациям, и отображает
информацию в разрезе конкретной организации.
Виджет должен корректно работать на объемах до 100 объектов у
пользователя. Загрузка виджета должна происходить асинхронно, т.е. не блокировать
загрузку остальных элементов на странице.
Виджет отображает информацию за последние сутки.
Первичной информацией для виджета является информация, отображаемая в
подразделе «Контроль превышения фактического теплопотребления от проектного»
раздела «Энергоэффективность».
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.8
Доработка
формирования
отчета
в
модуле
«Реестры»,
раздел
«Превышение лимитов потребления» в части выбора муниципального
образования без привязки к подключенным объектам
В форму заказа отчета «Превышение лимитов потребления» необходимо
добавить поле выбора муниципального образования в разделе формирования отчета.
57
Для пользователей с ролью «Система. Администратор», «ОГВ» и «ОМС»
должен быть доступен режим формирования отчета без учета привязки объектов к
организации пользователя. По умолчанию, для таких пользователей этот режим
должен быть включен.
Остальным пользователям, формирование отчета должно вестись по
доступным им объектам.
Для отчета должна быть реализована печатная форма, состав полей которой
подбирается Исполнителем на этапе технического проектирования.
На этапе технического проектирования, Исполнитель может добавлять и
уточнять состав полей. Уточнение состава полей фиксируется в частном техническом
задании или в дополнительном соглашении.
8.9
О
замене
системы
управления
базами
данных
в
целях
импортозамещения и повышения уровня защиты информации
В рамках реализации стратегии технологического развития и обеспечения
независимости используемого программного стека принято решение о замене
системы управления базами данных PostgreSQL на отечественный продукт Postgres
Pro.
Данный
шаг
обусловлен
необходимостью
перехода
на
коммерчески
поддерживаемое решение с гарантированным уровнем сервисного обслуживания,
прогнозируемым жизненным циклом версий и расширенными средствами защиты
информации. Переход с PostgreSQL на Postgres Pro будет осуществлен в рамках
Контракта на развитие на 2026 год и позволит обеспечить бесперебойную и
безопасную эксплуатацию информационной системы в долгосрочной перспективе и
обеспечит завершение миграции без потери функциональности и с сохранением
штатной работы Подсистемы.
58
9
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ПОДСИСТЕМЫ
9.1
Виды испытаний и внедрение доработанной Подсистемы
Испытания проводятся с целью проверки соответствия доработанной
Подсистемы требованиям настоящего Технического задания.
До ввода доработанной Подсистемы в эксплуатацию обязательно провести
следующие виды испытаний в рамках выполнения работ по контракту:
 предварительные испытания;
 опытная эксплуатация;
 приемочные испытания.
Содержание
и
оформление
документов
«Программа
и
методика
предварительных испытаний», «Программа и методика опытной эксплуатации»,
«Программа и методика приемочных испытаний» должны учитывать требования
ГОСТ
Р
59792-2021
«Национальный
стандарт
Российской
Федерации.
Информационные технологии. Комплекс стандартов на автоматизированные
системы. Виды испытаний автоматизированных систем» и ГОСТ 19.301-79* (СТ СЭВ
3747-82) «Государственный стандарт Союза ССР. Единая система программной
документации. Программа и методика испытаний. Требования к содержанию и
оформлению».
Программа и методика испытаний разрабатывается Исполнителем в рамках
частного технического задания и предоставляется Заказчику не позднее даты
указанной в таблице 9.1, должна включать в себя необходимые для полноценной
проверки и испытаний тесты (контрольные примеры), которые обеспечивают полную
проверку функций и процедур по перечню, определенному в техническом задании.
59
Таблица 9.1 ПЛАН-ГРАФИК ПРОВЕДЕНИЯ ИСПЫТАНИЙ
Результат и подтверждающие
Этап испытаний
Длительность / Срок
Ответственный за проведение
Основные задачи и мероприятия
документы (согласно
Приложению 4)
1. Разработка и согласование с Заказчиком
программ и методик испытаний (для всех
этапов:
предварительных,
эксплуатации,
1. Подготовка к испытаниям
до 13.11.2026
Исполнитель
2.
опытной
приемочных).
Подготовка
тестовых
данных
и
• Программа
и
методика
предварительных
испытаний
• Программа и методика опытной
сценариев (контрольных примеров) для
эксплуатации
проверки всего функционала из Раздела 8
• Программа
ТЗ.
приемочных испытаний
и
методика
3. Развертывание доработанной версии
ПО на боевой системе.
1.
Проверка
новых
и
работоспособности
доработанных
всех
функций
из
Раздела 8 ТЗ (Контроль превышения
теплопотребления,
Контроль
температурного графика, новые виджеты,
печатные
2. Предварительные испытания
10 календарных дней (13.11-
Исполнитель (с участием Заказчика
23.11.2026)
для фиксации результатов)
2.
формы
Проверка
взаимодействий
и
т.д.).
интеграционных
(API)
с
внешними
системами (РГИС Энергоэффективность,
ФГИС
Аршин
и
др.).
• Протокол
предварительных
испытаний.
• Решение
о
перехода
возможности
к
опытной
эксплуатации.
3. Проверка корректности установки и
настройки ПО на тестовом контуре.
4. Проверка документации на полноту и
соответствие.
3. Опытная эксплуатация (ОЭ)
1. Приказ Заказчика о начале ОЭ.
• Приказ
о
начале
ОЭ.
2. Работа пользователей в системе в
• Журнал опытной эксплуатации.
10 календарных дней (23.11-
Заказчик / Функциональный
реальном режиме. Выполнение реальных
• Протокол
02.12.2026)
заказчик (Пользователи)
бизнес-задач с использованием нового
эксплуатации (составляется по
функционала.
итогам,
3.
60
Исполнитель
осуществляет
выявленные
опытной
фиксируются
и
устраненные
Результат и подтверждающие
Этап испытаний
Длительность / Срок
Ответственный за проведение
Основные задачи и мероприятия
документы (согласно
Приложению 4)
техническую поддержку, консультирует
пользователей, оперативно исправляет
выявленные
критичные
ошибки.
4. Проверка корректности формирования
недостатки).
• Решение о возможности перехода
к приемочным испытаниям
отчетов, печатных форм.
1. Комплексная проверка системы в
полном объеме согласно утвержденной
"Программе и методике приемочных
испытаний".
2.
Демонстрация
Исполнителем
всех
функций ТЗ.
3.
Проверка
переданной
полноты
и
качества
документации,
исходных
кодов, инструкций по развертыванию.
4. Проверка способности системы к
восстановлению
5.
4. Приемочные испытания
8 рабочих дней (03.12 14.12.2026)
Приемочная комиссия (Заказчик,
Функциональный заказчик,
Исполнитель)
Анализ
после
сбоев.
результатов
опытной
эксплуатации.
6. Подписание членами комиссии Акта
приемочных
испытаний
(при
положительном результате).
7.
Подписание
Акта
сдачи-приемки
выполненных работ (Технического акта,
Приложение №1).
8. Передача всех исключительных прав
(подписание
Акта
приема-передачи
исключительных прав).
9.
Подписание
Акта
о
приемке
в
постоянную эксплуатацию.
10. Размещение документа о приемке в
ЕИС.
61
• Протокол
испытаний
приемочных
(с
итоговым
заключением).
• Акт приемочных испытаний.
• Акт о приемке в постоянную
эксплуатацию.
• Технический акт (приложение №1).
• Акт-приема
передачи
исключительных прав.
• Акт приемки-сдачи выполненных
работ.
• Размещение документа о приемке в
ЕИС.
9.2
Проведение профилактических работ
Проведение профилактических работ, влияющих на производительность
Подсистемы, допускается в нерабочее время и выходные дни по согласованию с
Заказчиком. Длительность профилактических работ в Подсистеме не должна
превышать 4 часов (за исключением ситуации физического выхода из строя
программно-технических средств). Срок выполнения запроса на оказание поддержки
пользователей,
связанной
с
расширением
и
изменением
функциональных
возможностей Подсистемы, должен зависеть от приоритета задачи. Исполнитель
должен оповестить пользователей Подсистемы о планируемых технических
мероприятиях.
9.3
Передача исходных кодов
Для вновь разрабатываемых и модернизируемых компонентов Подсистемы
Исполнитель должен передать Заказчику: скомпилированные и исходные коды,
дистрибутивы, для которых Исполнителем должна быть проведена проверка сборки
(компиляции) и последующего запуска с подтверждением функционирования
заявленных задач, а также инструкция проведения такой сборки (компиляции),
содержащая все необходимые для сборки и запуска компонентов Подсистемы
библиотек зависимостей, инструкций и программных сценариев (скриптов) для
проведения компиляции, создания дистрибутива и установки (развертывания)
компонентов Подсистемы, а также пароли от дистрибутивов, позволяющие
произвести открытие без повреждения данных. Исходные программные коды должны
содержать документирующие комментарии, описывающие назначение объекта
программы, смысл входных/выходных параметров для функции/процедуры, примеры
использования,
возможные
исключения,
особенности
реализации.
Документирующие комментарии должны быть оформлены как многострочные
комментарии перед документируемым элементом.
Дистрибутив
должен
иметь
средства,
подтверждающие
отсутствие
несанкционированных изменений. Подтверждение отсутствия фактов внесения
62
несанкционированных изменений в дистрибутив осуществляется посредством
сравнения контрольной суммы (ГОСТ Р 34.11-2012 «Национальный стандарт
Российской Федерации. Информационная технология. Криптографическая защита
информации.
Функция
хэширования»)
этого
дистрибутива,
указанной
в
документации на поставку.
Исходные коды должны быть организованы в логическую структуру с
соблюдением принятых стандартов кодирования, оформлены в виде репозитория с
понятной навигацией, что обеспечивает возможность их анализа, доработки и
сопровождения для Заказчика.
Вместе с исходными кодами должны быть переданы файлы конфигурации
и/или скрипты автоматизированной сборки (например, Makefile, Dockerfile, CI/CD
т.д.),
обеспечивающие
воспроизводимость
и
воспроизводимую
сборку
на
изолированной среде.
При наличии в составе исходных кодов сторонних библиотек и модулей,
поставляемых по открытым лицензиям, Исполнитель обязан предоставить перечень
таких компонентов с указанием лицензий, под которыми они распространяются, а
также
подтвердить
соответствие
условий
их
использования
требованиям
законодательства РФ и условиям Контракта.
Исполнитель несёт ответственность за полноту передаваемых исходных
материалов, их актуальность и соответствие финальной версии функционирующей
системы, в том числе за возможность их сборки и запуска без дополнительных
неофициальных зависимостей и скрытых настроек.
9.4
Общие требования к приемке работ
Приемка результатов работ осуществляется в соответствии с разделом 9
настоящего Описания объекта закупки и разделом 6 проекта государственного
контракта.
По завершении работ Исполнитель предоставляет Заказчику результаты
работ. По завершении работ Исполнитель письменно уведомляет Заказчика о
готовности к сдаче работ и предоставляет Заказчику отчетные документы по
выполненным работам с сопроводительным письмом. Не позднее 2 (Двух) рабочих
63
дней, следующих за днем окончания выполнения работ, Исполнитель размещает в
единой информационной системе (ЕИС) документ о приемке.
При приемке результатов работ по каждому этапу работ, в которых
требовалось дорабатывать ПО, Исполнитель выполняет инсталляцию программного
обеспечения на оборудовании Заказчика, выполняет проверку работоспособности и
соблюдения функциональных требований настоящего Технического задания.
Исполнитель
разворачивает
и
настраивает
программное
обеспечение
Подсистемы в центре обработки данных Правительства Ленинградской области.
Испытания Подсистемы проводиться на АРМ Исполнителя/Функционального
заказчика согласно письменному уведомлению Заказчика о месте, дате и времени
проведения
испытаний.
Исполнитель
устанавливает
и
настраивает
общее/специальное программное обеспечение в ЦОД ЛО и на демонстрационном
автоматизированном рабочем месте. Заказчик письменно уведомляет Исполнителя о
месте и времени проведения приемки выполненных работ.
Приемка результатов выполненных работ проводится комиссией, в течение 20
(двадцати) рабочих дней с момента предоставления всех результатов работ по этапу.
Состав комиссии утверждается Заказчиком.
Председателем комиссии назначается представитель Заказчика. Со стороны
Функционального заказчика назначаются ответственные лица для включения в состав
приемочной комиссии по запросу Заказчика.
Исполнитель предоставляет комплект отчетных документов по результатам
выполненных
работ
и
проводимых
испытаний.
Результаты
выполненных
работ/испытаний должны быть зафиксированы в протоколах и актах. Протоколы и
акты подписываются всеми членами комиссии.
При положительном результате приемки выполненных работ у Исполнителя
подписывается протокол и акт всеми членами комиссии.
При отрицательном результате приемки выполненных работ у Исполнителя
подписываются протокол и акт всеми членами комиссии с фиксацией недостатков и
ошибок в реализации программного обеспечения, выявленных в ходе проведения
испытаний (предварительных испытаний; приемочных испытаний) и назначается
64
дата повторной приемки выполненных работ. Недостатки и замечания, указанные в
протоколе, должны быть устранены Исполнителем в согласованный с Заказчиком
срок.
В случае отсутствия замечаний к представленной Подсистеме, Заказчик
подписывает документ о приемке выполненных работ.
Недостатки и ошибки в реализации программного обеспечения Подсистемы,
выявленные в ходе приемки, должны быть устранены Исполнителем в рамках
выполнения Контракта, если только Сторонами не согласовано, что, исходя из
характера недостатков, они могут устраняться в рамках гарантийных обязательств
Исполнителя. Сроки и формат устранения замечаний и реализации рекомендаций,
данных комиссией в ходе испытаний, определяются в соответствующих протоколах.
Оформляются как недостатки реализации работ, исключительно выявленные как
отклонения от настоящего Технического задания, прочие недостатки могут
документироваться как желательные доработки.
Приемка работ по этапу, включающему доработку или разработку
программного обеспечения, осуществляется только при наличии переданных
Заказчику исходных кодов, а также актуальной технической и пользовательской
документации. Документация должна быть предоставлена в электронном и бумажном
виде, пригодном для последующего сопровождения.
9.5
Требования информационной безопасности при проведении работ по
развитию информационной системы
9.5.1 Требования информационной безопасности
Исполнитель выполняет мероприятия по информационной безопасности на
объектах
информатизации,
взаимодействующих
с
государственными
информационными системами Ленинградской области (далее - ГИС ЛО), в рамках
государственного контракта (далее - ГК), в соответствии с требованиями
федерального законодательства, законодательства Ленинградской области по
информационной
безопасности,
организационными
документами по информационной безопасности ГИС ЛО.
65
и
распорядительными
Доступ Исполнителя к ГИС ЛО осуществляется при наличии аттестатов
соответствия объектов информатизации требованиям информационной безопасности
не ниже требований, предъявляемым к ГИС ЛО.
Не допускается копирование Исполнителем информации, к которой им
предоставлен доступ, если такое копирование не предусмотрено в документах ГИС
ЛО, на основании которых Исполнителю предоставлен доступ к информационным
системам.
Исполнитель обязан исключить возможность несанкционированного доступа
или воздействий на ГИС ЛО и содержащуюся в ней информацию через
взаимодействующие с ГИС ЛО программно-аппаратные средства Исполнителя или
каналы передачи данных и интерфейсы, используемые Исполнителем для доступа
к информационным системам.
9.5.2 Требования к наличию лицензий
Исполнитель должен иметь действующие лицензии:
9.5.1.1 Лицензия ФСБ России на право осуществлять деятельность по
разработке, производству, распространению шифровальных (криптографических)
средств, информационных систем и телекоммуникационных систем, защищенных с
использованием шифровальных (криптографических) средств, выполнение работ,
оказание услуг в области шифрования информации, техническому обслуживанию
шифровальных
(криптографических)
средств,
информационных
систем
и
телекоммуникационных систем, защищенных с использованием шифровальных
(криптографических)
средств
(за
исключением
случая,
если
техническое
обслуживание шифровальных (криптографических) средств, информационных
систем
и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных (криптографических) средств, осуществляется для обеспечения
собственных нужд юридического лица или индивидуального предпринимателя) в
части работ, предусмотренных пунктами 2, 12 Перечня выполняемых работ и
оказываемых услуг, составляющих лицензируемую деятельность, в отношении
шифровальных (криптографических) средств, утвержденному постановлением
Правительства Российской Федерации от 16.04.2012 № 313 «Об утверждении
66
Положения
о
лицензировании
деятельности
по
разработке,
производству,
распространению шифровальных (криптографических) средств, информационных
систем
и
телекоммуникационных
систем,
защищенных
с
использованием
шифровальных (криптографических) средств, выполнению работ, оказанию услуг в
области шифрования информации, техническому обслуживанию шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств
(за
исключением
случая,
если
техническое
обслуживание
шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств,
осуществляется для обеспечения собственных нужд юридического лица или
индивидуального предпринимателя)», а именно «разработка защищенных с
использованием шифровальных (криптографических) средств информационных
систем»,
«монтаж,
установка
(инсталляция),
наладка
шифровальных
(криптографических) средств, за исключением шифровальных (криптографических)
средств защиты фискальных данных, разработанных для применения в составе
контрольно-кассовой
техники,
сертифицированных
Федеральной
службой
безопасности Российской Федерации, и шифровальных (криптографических)
средств, разработанных для применения в составе технологии, реализуемой
промежуточными элементами интеллектуальной системы учета электрической
энергии (мощности) и приборами учета электрической энергии, сертифицированных
Федеральной службой безопасности Российской Федерации».
Требование установлено на основании подпункта 1 пункта 1 статьи 12
Федерального закона от 04.05.2011 № 99-ФЗ «О лицензировании отдельных видов
деятельности», а именно «разработка, производство, распространение шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств,
выполнение работ, оказание услуг в области шифрования информации, техническое
обслуживание шифровальных (криптографических) средств, информационных
систем
и
телекоммуникационных
систем,
67
защищенных
с
использованием
шифровальных (криптографических) средств (за исключением случая, если
техническое
обслуживание
шифровальных
(криптографических)
средств,
информационных систем и телекоммуникационных систем, защищенных с
использованием шифровальных (криптографических) средств, осуществляется для
обеспечения
собственных
нужд
юридического
лица
или
индивидуального
предпринимателя)».
В случае отсутствия у Исполнителя действующей лицензии возможно
привлечение Соисполнителя.
9.5.1.2 Лицензия ФСТЭК России на право осуществления деятельности
по технической защите конфиденциальной информации в части работ,
предусмотренных подпунктом «д» и «е» пункта 4 Положения о лицензировании
деятельности
по
технической
защите
конфиденциальной
информации,
утвержденного постановлением Правительства Российской Федерации от 03.02.2012
№ 79 «О лицензировании деятельности по технической защите конфиденциальной
информации», а именно «работы и услуги по проектированию в защищенном
исполнении средств и систем информатизации» и «услуги по установке, монтажу,
наладке, испытаниям, ремонту средств защиты информации (программных
(программно-технических) средств защиты информации)».
Требование установлено в соответствии с подпунктом 5 пункта 1 статьи
12 Федерального закона от 04.05.2011 № 99-ФЗ «О лицензировании отдельных
видов
деятельности»,
а
именно
«деятельность
по
технической
защите
конфиденциальной информации».
Наличие п. 9.5.1.2 указанной лицензии обусловлено требованиями пунктами
5. «Требования к моделированию угроз безопасности информации», 4. «Требования к
разработке организационных, организационно-технических и распорядительных
документов по информационной безопасности при выполнении работ по развитию
ГИС ЛО, обрабатывающих информацию ограниченного доступа (далее - ПДн)».
В случае отсутствия у Исполнителя действующей лицензии возможно
привлечение Соисполнителя.
68
9.5.3 Требования к удаленному доступу
При необходимости удаленного доступа для Исполнителя такой доступ
предоставляется в соответствии с Областным Законом Ленинградской области № 60оз от 18.07.2016 «О государственных информационных системах Ленинградской
области» и постановлением Правительства Ленинградской области от 19 июня 2017
года № 229 «О правилах присоединения к единой сети передачи данных
Ленинградской области и правилах ее использования». При предоставлении
удаленного доступа Исполнитель осуществляет мероприятия по информационной
безопасности
на
объектах
информатизации
со
стороны
Исполнителя,
взаимодействующих с ГИС ЛО, в соответствии с требованиями федерального
законодательства и законодательства Ленинградской области по информационной
безопасности,
организационными
и
распорядительными
документами
по
информационной безопасности ГИС ЛО.
Удаленный доступ Исполнителя к Системе:
9.5.3.1 Не позднее 5 рабочих дней, следующего за днем заключения
Государственного контракта Исполнитель:
9.5.3.2 подает заявку Заказчику на присоединение к единой сети передачи
данных Ленинградской области (далее - ЕСПД);
9.5.3.3 подает заявку Заказчику на разграничение доступа к государственным
информационным ресурсам и системам Ленинградской области для субъектов, не
являющихся органом исполнительной власти Ленинградской области (при наличии
программного обеспечения защиты информации для защищённой сети ViPNet 6440);
9.5.3.4 В случае получения Заказчиком заявки в соответствии с п. 9.5.3.2
программное обеспечение защиты информации для защищённой сети ViPNet 6440
передается Исполнителю по Акту приема-передачи во временное пользование
на срок не более 60 календарных дней с целью возможности исполнения
Контракта до приобретения Исполнителем программного обеспечения (далее - ПО)
ViPNet за счет собственных средств;
9.5.3.5 В случае получения заявки, указанной в п. 9.5.3.3, Заказчик в срок не
позднее 5 (пяти) рабочих дней предоставляет соответствующий доступ;
69
9.5.3.6 Формы заявок, указанных в п. 9.5.3.2 и дополнительная информация о
присоединении к ЕСПД указана на сайте государственного казенного учреждения
Ленинградской области «Оператор «электронного правительства» (далее - ГКУ ЛО
«ОЭП») по адресу https://egov.lenreg.ru/?page_id=1276;
9.5.3.7 Исполнитель
обязан
исключить
возможность
использования
предоставленного удаленного доступа третьими лицами.
9.5.4. Требования к разработке организационных, организационно –
технических и распорядительных документов по информационной безопасности
при осуществлении развития ГИС ЛО.
9.5.4.1 Исполнитель разрабатывает (актуализирует) документ «Меры защиты
информации в ГИС ЛО в соответствии с требованиями и рекомендациями
федерального органа исполнительной власти в области обеспечения безопасности и
федерального
органа
исполнительной
власти,
уполномоченного
в
области
противодействия техническим разведкам и технической защиты информации.
Документ «Меры защиты информации в ГИС ЛО» должен содержать:
Перечень
организационных
и
технических
мер
по
обеспечению
информационной безопасности системы при ее эксплуатации;
Перечень
организационно-распорядительных
документов
по
информационной безопасности, разработка которых необходима в соответствии с
требованиями законодательства Российской Федерации, с указанием конкретных
пунктов и наименований нормативных, правовых, регулирующих, методических
документов, содержащих требования;
Перечень необходимых средств защиты информации, необходимых для
использования в ГИС ЛО, в том числе на автоматизированном рабочем месте,
серверном и коммутационном оборудовании.
Документ «Меры защиты информации в ГИС ЛО» согласуется с Заказчиком и
отделом
информационной
безопасности
Ленинградской области.
70
Комитета
цифрового
развития
9.5.4.2. Исполнитель актуализирует (разрабатывает при необходимости)
проекты: Акт классификации информационной системы, Акт определения уровня
защищенности ПДн при их обработке в информационной системе ПДн.
Форма
Акта
классификации
информационной
системы
должна
соответствовать приложению 3 к приказу ФСТЭК России от 29 апреля 2021 г. № 77.
Проекты актов согласуются с Заказчиком и отделом информационной
безопасности Комитета цифрового развития Ленинградской области.
9.5.4.3 Исполнитель актуализирует (разрабатывает при необходимости)
организационно-распорядительные и эксплуатационные документы, в частности:
–
технический паспорт ГИС ЛО;
–
журналы по защите информации;
–
матрицу доступа ГИС ЛО;
–
инструкции пользователя и администратора ГИС ЛО;
–
иные документы, указанные в документе «Меры по защите информации
в ГИС ЛО». Организационно-распорядительные документы не должны быть
типовыми и должны содержать актуальные сведения о ГИС ЛО.
9.5.5 Требования к моделированию угроз безопасности
С учетом целей развития и назначения Системы, предусматривается обработка
информации
ограниченного
доступа
(персональных
данных),
а
также
технологической информации, в том числе служебной информации о работе системы
защиты информации, и общедоступной информации.
Исполнитель проводит работы по актуализации (разработке) модели угроз
безопасности
информации
Системы,
в
соответствии
с
требованиями
и
рекомендациями федерального органа исполнительной власти в области обеспечения
безопасности и федерального органа исполнительной власти, уполномоченного в
области
противодействия
техническим
разведкам
и
технической
защиты
информации.
Структура и содержание Модели угроз безопасности информации Системы
должна соответствовать приведенной в Приложении № 3 к методическому документу
71
«Методика оценки угроз безопасности информации», утвержденному ФСТЭК России
05.02.2021.
Модель
угроз
должна
учитывать
совокупность
предположений
о
возможностях, которые могут использоваться при создании способов, подготовке и
проведении атак с целью нарушения безопасности, защищаемых средствами
криптографической защиты информации (далее - СКЗИ), персональных данных в
Системе в соответствии с требованиями приказа ФСБ России от 10.07.2014 № 378 «Об
утверждении Состава и содержания организационных и технических мер по
обеспечению
безопасности
персональных
данных
при
их
обработке
в
информационных системах персональных данных с использованием средств
криптографической
защиты
информации,
необходимых
для
выполнения
установленных Правительством Российской Федерации требований к защите
персональных данных для установленного уровня защищенности» и требованиями
документа «Методические рекомендации по разработке нормативных правовых
актов, определяющих угрозы безопасности персональных данных, актуальные при
обработке персональных данных в информационных системах персональных данных,
эксплуатируемых при осуществлении соответствующих видов деятельности»,
утвержденного 8 Центром ФСБ России 31.03.2015 №149/7/2/6-432.
По результатам моделирования угроз безопасности информации при развитии
ГИС Исполнитель представляет в Комитет цифрового развития Ленинградской
области актуализированную модель угроз и Заключение о необходимости проведения
дополнительных аттестационных испытаний или повторной аттестации, либо об
отсутствии необходимости проведения указанных мероприятий.
Комитет цифрового развития Ленинградской области по результатам
рассмотрения Заключения принимает решение о направлении модели угроз на
согласование в Федеральный орган исполнительной власти в области обеспечения
безопасности и Федеральный орган исполнительной власти, уполномоченный в
области противодействия техническим разведкам и технической защиты информации
(далее – Уполномоченные органы).
72
В случае получения замечаний от Уполномоченных органов Исполнитель
принимает меры к их устранению и повторно представляет модель угроз в Комитет
цифрового развития Ленинградской области для дальнейшего направления на
согласование в Уполномоченные органы. Устранение замечаний Уполномоченных
органов производится Исполнителем в рамках гарантийных обязательств, в случае
поступления таких замечаний по истечении срока исполнения Контракта.
9.5.5.1 Требования к выполнению работ по проведению аттестационных
испытаний/аттестации (при необходимости)
Аттестационные испытания/аттестация информационной системы (при
необходимости) организуется отделом информационной безопасности Комитета
цифрового развития Ленинградской области (далее – отдел ИБ КЦР) и включает
проведение
комплекса
организационных
и
технических
мероприятий
(аттестационных испытаний), в результате которых подтверждается соответствие
системы защиты информации информационной системы Требованиям о защите
информации,
не
составляющей
государственную
тайну,
содержащейся
в
государственных информационных системах.
Для проведения работ по аттестации Исполнитель предоставляет:
1.
Модель угроз;
2.
Перечень информации, обрабатываемой в ГИС ЛО, и подлежащей
защите (согласно приложению № 1);
3.
Технический паспорт ГИС ЛО;
4.
Меры защиты информации в ГИС ЛО;
5.
Журналы по защите информации;
6.
Матрицу доступа ГИС ЛО;
7.
Инструкции пользователя и администратора ГИС ЛО;
8.
Иные документы, указанные в документе «Меры по защите информации
в ГИС ЛО».
9.
Акт классификации ГИС ЛО;
10. Акт определения уровня защищенности.
73
9.5.6 Требования к устранению уязвимостей
9.5.6.1 В рамках выполнения работ Исполнитель обязан осуществить
устранение уязвимостей, выявленных на разрабатываемом функционале Системы, до
момента направления уведомления Заказчику о готовности к предварительным
испытаниям результатов.
9.5.6.2 Сканирование на наличие уязвимостей осуществляется Заказчиком:
При выполнении работ на СПО Системы: сканированию подлежит только
предоставленный Исполнителем исходный код;
При выполнении работ на ОПО (включая замену операционной системы,
СУБД и других системных компонентов): сканированию подлежит разрабатываемый
функционал Системы.
9.5.6.3 По результатам проведения сканирования Заказчик направляет
Исполнителю в течение 3-х календарных дней перечень выявленных уязвимостей
через деловую почту ViPNet или сообщает об их отсутствии.
В случае выявления уязвимостей Исполнитель составляет «Отчет по
результатам устранению уязвимостей» (далее - Отчет) содержащий:
– перечень уязвимостей;
– уровень опасности уязвимостей;
– описание способа устранения уязвимостей;
– дата устранения уязвимостей.
В
случае,
если
устранение
технологическими
и/или
организационными
Заказчика,
Исполнитель
направляет
уязвимости
невозможно
ограничениями
Заказчику
и
отделу
в
связи
с
инфраструктуры
информационной
безопасности Комитета цифрового развития Ленинградской области (далее – отдел
ИБ КЦР) в составе Отчета:
– компенсирующие меры защиты;
– альтернативные меры защиты;
– обоснование невозможности устранения;
74
– рекомендации по устранению уязвимостей.
Для подтверждения устранения уязвимостей выполняется контрольное
сканирование по дополнительному запросу Исполнителя, результаты прилагаются к
Отчёту.
Отчет предоставляется Заказчику не позднее чем за 3 (три) календарных дня до
направления уведомления о готовности к предварительным испытаниям результатов.
9.5.6.4 Заказчик, отдел ИБ КЦР имеют право на внеплановое сканирование
Системы, по результатам которого Исполнитель выполняет мероприятия
в соответствии с п. 9.5.6.3.
9.5.6.5 Все выявленные в ходе действия ГК уязвимости безопасности на
разрабатываемом функционале Системы должны быть устранены Исполнителем.
При наличии уязвимостей, на разрабатываемом функционале Системы, которые не
были устранены в течение действия ГК, за исключением случаев, указанных в п.
9.5.6.3 Заказчик вправе признать ГК неисполненным.
9.5.6.6 Результатом анализа (мониторинга) уязвимостей Системы является
подтверждение отсутствия уязвимостей в Системе, содержащихся в банке данных
угроз
безопасности
информации
ФСТЭК
использования (эксплуатации) нарушителем.
75
России,
или
невозможности
их
10
ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ
ПО ПОДГОТОВКЕ ПОДСИСТЕМЫ К ВВОДУ В ДЕЙСТВИЕ
Результаты
оформляться
выполненных
Исполнителем
и
работ
по
развитию
предъявляться
Подсистемы
Заказчику
в
должны
соответствии
с
требованиями описания объекта закупки.
При этом все созданные в ходе выполнения работ результаты работ
принадлежат Заказчику.
Исполнитель не позднее даты окончания работ предоставляет Заказчику
отчетные документы согласно Приложению 4 настоящего ООЗ:
Все отчетные документы (журнал и отчеты) передаются Исполнителем
Заказчику в бумажном виде.
Акт
сдачи-приемки
выполненных
работ
направляется
Заказчику
в
соответствии с условиями заключенного контракта.
Исполнитель гарантирует корректность информации, содержащейся в
отчетных документах, и ее соответствие техническому состоянию Подсистемы, и
информации, содержащейся в Подсистеме - по состоянию на отчетную дату.
Установление факта несоответствия информации, содержащейся в отчетных
документах, техническому состоянию Подсистемы и информации, содержащейся в
Подсистеме, на отчетную дату является основанием для отказа от приемки
выполненных работ.
В случае обнаружения Заказчиком и документального подтверждения
недостоверных сведений в отчетных документах, Исполнитель обязан в течение 5
(пяти) рабочих дней с даты уведомления Заказчиком предоставить исправленные
документы. Повторное нарушение является основанием для направления претензии и
применения мер ответственности, предусмотренных контрактом.
Формы и структура отчетных документов, состав показателей, объем данных и
периодичность отчетности согласовываются Сторонами до начала выполнения работ
и оформляются приложением к Техническому заданию или Контракту.
76
11
ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
Документы, разрабатываемые в рамках настоящего ООЗ и относящиеся к
модифицированному
ПО
Подсистемы
должны
удовлетворять
требованиям
комплекса стандартов и руководящих документов на автоматизированные системы.
Все документы должны быть оформлены в едином стиле.
Порядок оформления и предъявления Заказчику результатов выполнения
работ в соответствии с рекомендациями следующих нормативных документов,
регламентирующим создание автоматизированных систем в сфере информационных
технологий:
 ГОСТ 34.201–2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы. Виды,
комплектность
и
обозначение
документов
при
создании
автоматизированных систем»;
 ГОСТ 34.602–2020 «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы»;
 ГОСТ Р 59792–2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Виды испытаний автоматизированных
систем»;
 ГОСТ Р 59793–2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Стадии
создания».
Выходной
контроль
специализированным
документов
подразделением
на
Подсистему
Исполнителя
в
выполняется
соответствии
с
государственными стандартами и методическими указаниями. Описание и состав
разделов документации/документов может быть изменен Заказчиком в рабочем
порядке.
77
Заказчик вправе контролировать ход и качество оказанных работ, соблюдение
Исполнителем сроков их выполнения, получать информацию о промежуточных
результатах выполнения работ.
Оказываемые работы должны быть безопасны для жизни, здоровья людей,
имущества Заказчика и окружающей среды при обычных условиях их выполнения в
соответствии с Федеральным законом РФ от 30.03.1999 № 52-ФЗ «О санитарноэпидемиологическом благополучии населения».
78
12
ИСТОЧНИКИ РАЗРАБОТКИ
В качестве источников разработки технического задания использовались
следующие документы:
 Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об
информации, информационных технологиях и о защите информации».
 Методический документ ФСТЭК России «Методика оценки угроз
безопасности информации», утвержденная 05.02.2021.
 Приказ ФСТЭК России от 04.07.2022 № 118 «Об утверждении требований
по безопасности информации к средствам контейнеризации».
 ГОСТ 34.201-2020 – «Межгосударственный стандарт. Информационные
технологии. Комплекс стандартов на автоматизированные системы. Виды,
комплектность
и
обозначение
документов
при
создании
автоматизированных систем»;
 ГОСТ Р 59792-2021 «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Виды испытаний автоматизированных
систем»;
 ГОСТ Р 59793-2021 – «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Стадии
создания»;
 ГОСТ Р 59795-2021. «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Требования
к содержанию документов»;
 ГОСТ Р 59853-2021 – «Национальный стандарт Российской Федерации.
Информационные
технологии.
Комплекс
стандартов
на
автоматизированные системы. Автоматизированные системы. Термины и
определения»;
79
 ГОСТ 19.301-79* (СТ СЭВ 3747-82) «Государственный стандарт Союза
ССР. Единая система программной документации. Программа и методика
испытаний. Требования к содержанию и оформлению».

80
13
ПРИЛОЖЕНИЯ
Перечень приложений к настоящему Описанию объекта закупки:
 Приложение № 1 «Образец технического акта».
 Приложение № 2 «Сведения о местах выполнения работ».
 Приложение № 3 «Расчет стоимости выполнения работ».
 Приложение № 4 «Перечень отчетных документов, передаваемых
Заказчику».
 Приложение № 5 «Перечень информации, обрабатываемой в ГИС ЛО, и
подлежащей защите».
 Приложение № 6 «Обоснование невозможности соблюдения запрета по
предоставлению национального режима при осуществлении закупок
товаров, работ, услуг для обеспечения государственных нужд, закупок
товаров, работ, услуг отдельными видами юридических лиц».
81
Приложение № 1
к Описанию объекта закупки
ОБРАЗЕЦ
Технический акт
по государственному контракту № ___________ от ______________
на выполнение работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития Подсистемы «Учет
потребления коммунальных ресурсов Ленинградской области»
Санкт-Петербург
«____»_________ ____ г.
Приемочная комиссия, действующая на основании приказа государственного казенного
учреждения Ленинградской области «Центр энергосбережения и повышения энергоэффективности
Ленинградской области» (далее – ГКУ ЛО «ЦЭПЭ ЛО»)
от _______________________ № _________ (далее – Комиссия) составила настоящий акт о
нижеследующем:
1. Комиссия рассмотрела результаты выполнение работ по государственному контракту от
_________ № ___________________ за счет средств бюджета Ленинградской области на 202__ год,
государственная программа «_________», подпрограмма «_____________», основное мероприятие
«________», раздел/подраздел ____, КЦСР _______, КВР_____, КОСГУ ______, ДопКР _______
между ГКУ ЛО «ЦЭПЭ ЛО» (далее – Заказчик) и _________________________ (далее –
Исполнитель) на выполнение работ по развитию региональной государственной информационной
системы жилищно-коммунального хозяйства Ленинградской области в части развития Подсистемы
«Учет потребления коммунальных ресурсов Ленинградской области» (далее – Контракт), за
отчетный период с ______________ по __________________.
2.
2.1.
Комиссия установила:
Исполнитель за отчетный период с _____________ по ____________ выполнил работы:




По факту выполнение работ подлежит оплате ________________ (______________________), в том
числе НДС ____________________________.
2.2. Исполнитель по результатам выполненных работ представил Заказчику комплект отчетных
документов:



82
2.3. Объем, содержание и качество выполненных работ соответствуют требованиям Описания
объекта закупки. В ходе приёмки недостатков не выявлено.
2.4. Состав, комплектность и содержание отчетных документов, представленных Исполнителем,
соответствует требованиям Описания объекта закупки.
3. Комиссия решила:
3.1. Считать, что Исполнитель выполнил работы по Контракту за отчетный период с _____________
по ______________ в срок и в полном объеме в соответствии с требованиями Описания объекта
закупки.
3.2. Принять результаты выполненных работ по Контракту за отчетный период с ___________ по
_______________.
Акт составлен в двух экземплярах:
1 экземпляр – Заказчику – Государственное казенное учреждение Ленинградской области «Центр
энергосбережения и повышения энергоэффективности Ленинградской области»;
2 экземпляр – Исполнителю – _____________________.
Исполнитель:
От _____________:
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
(должность)
(подпись)
(И.О. Фамилия)
Комиссия:
Заказчик:
от ГКУ ЛО «ЦЭПЭ ЛО»:
83
Приложение № 2
к описанию объекта закупки на выполнение работ по развитию Подсистемы региональной
государственной информационной системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов Ленинградской области»
Сведения о местах выполнения работ
№
п/п
Регион
1.
Санкт-Петербург
2.
Санкт-Петербург
3.
Санкт-Петербург
Адрес выполнение работ
Подсистема развернута на аппаратных мощностях ЦОД
Правительства Ленинградской области по адресу
Выборгское шоссе, д. 503, корп. 12
Государственное казенное учреждение Ленинградской
области «Центр энергосбережения и повышения
энергоэффективности Ленинградской области» СанктПетербург г., муниципальный округ Смольнинское
вн.тер.г., Калужский пер., дом 3, литера А
Комитет по топливно-энергетическому комплексу
Ленинградской области: г. Санкт-Петербург, ул.
Смольного, д. 3
84
Приложение № 3
к описанию объекта закупки на выполнение работ по развитию Подсистемы региональной
государственной информационной системы жилищно-коммунального хозяйства Ленинградской
области «Учет потребления коммунальных ресурсов Ленинградской области»
Расчет стоимости выполнения работ
№
Наименование услуг
1
1.1
1.2
1.3
1.4
1.5
1.6
Выполнение работ по развитию
региональной государственной
информационной системы
жилищно-коммунального
хозяйства Ленинградской области в
части развития Подсистемы «Учет
потребления коммунальных
ресурсов Ленинградской области»,
в том числе:
Разработка функциональной
возможности выбора периода
графика и реестра в функциональном
модуле «Контроль превышения
фактического теплопотребления от
проектного» раздела
«Энергоэффективность»
Разработка функциональной
возможности выбора периода в
модуле «Контроль температурного
графика» раздела
«Энергоэффективность»
Разработка функции «печатная
форма» по разделу «Контроль
температурного графика» из дерева
объектов по выбранному ресурсу
«Теплоснабжение» выбранного
объекта в разделе
Доработка модуля «Реестры» в
разделе формирования отчетности
«Сверхнормативное потребление
тепловой энергии», в части доработки
выбора района при формировании
отчета
Разработка экранной формы
«Контроль температурного графика»
по коммунальной услуге на уровне
объекта потребления
Добавление механизмов расчета
рекомендуемого расхода для
температурных графиков на уровне
объекта потребления, прибор объекта
Объем,
Ед.
измерения
Колво
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Цена за
ед. услуги без
НДС,
руб.
85
Цена за
ед.
услуги с
НДС,
руб.
Стоимос
ть услуг
без НДС,
руб.
Стоимос
ть услуг
с НДС,
руб.
1.7
1.8
1.9
Разработка интерактивного виджета
на стартовой странице с
функциональной информацией по
перерасходу тепловой энергии от
нормативного показателя в денежном
выражении
Доработка формирования отчета в
модуле «Реестры», раздел
«Превышение лимитов потребления»
в части выбора района без привязки к
подключенным объектам
Миграция (перенос) данных и
объектов схемы данных из текущей
СУБД PostgreSQL в целевую СУБД
Postgres Pro
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
86
Приложение № 4
к описанию объекта закупки на выполнение работ по развитию Подсистемы
региональной государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области «Учет потребления коммунальных ресурсов Ленинградской области»
Перечень отчетных документов, передаваемых Заказчику
№
п/п
1.
Наименование работ
Наименование отчетных документов
Работы по развитию Подсистемы
региональной государственной
информационной системы жилищнокоммунального хозяйства
Ленинградской области «Учет
потребления коммунальных ресурсов
Ленинградской области»
- акт приемочных испытаний;
- акт о приемке в опытную эксплуатацию;
- акты о приемке в постоянную эксплуатацию;
- акт приема-передачи исключительных прав;
- программа и методика предварительных
испытаний;
- программа и методика опытной эксплуатации;
- программа и методика приемочных испытаний;
- протокол приемочных испытаний;
- протокол опытной эксплуатации;
- протоколы тестирования (функционального,
нагрузочного, интеграционного) по требованию
Заказчика;
- схему структурного комплекса технических
средств (по требованию Заказчика);
- журнал опытной эксплуатации;
- целостные исходные коды, дистрибутивы
компиляторов, интерпретаторов и другого
программного обеспечения, библиотеки
зависимостей, плагины, инструкции и
программные сценарии (скрипты), инструкции по
развертыванию кодов (видео), базы данных;
- Технический акт передачи исходных кодов;
- Акт приемки-сдачи выполненных работ;
- Универсальный передаточный документ;
Приложение №5
к описанию объекта закупки на выполнение работ по развитию Подсистемы
региональной государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области «Учет потребления коммунальных ресурсов Ленинградской области»
87
ПЕРЕЧЕНЬ
информации, обрабатываемой в ГИС ЛО, и подлежащей защите
№
п/
п
Категория сведений
Основания
Наименование защищаемой
конфиденциального
отнесения к
информации
характера1
защищаемой
информации2
1
1.
Данные
приборами
об
оснащенности
учета
используемых
энергетических
государственных
Нет
(информация
ресурсов
и
относится к
муниципальных
публичной
учреждений
2
2.
информации)
Данные об объеме потребления
энергетических
государственных
Нет
Нет
Нет
ресурсов
и
(информация
муниципальных
относится к
публичной
информаци
учреждений
и
3
3.
Данные о поверках приборов
учета
энергетических
государственных
и
Нет
Нет
ресурсов
(информация
относится к
публичной
информаци
муниципальных
учреждений
и
4 Плановые и фактические значения
потребления энергетических ресурсов
4.
учреждений
государственных
и
Нет
Нет
(информация
относится
к
публичной
муниципальных образований
информации)
5
Плановые
и
фактические
Нет
Нет
В соответствии с Перечнем сведений конфиденциального характера, утвержденным Указом
Президента РФ от 6 марта 1997 г. N 188.
2
Номер пункта и реквизиты нормативного правового акта, устанавливающего соответствие
обрабатываемой информации категории сведений конфиденциального характера.
1
88
5.
значения
индикаторов
расчета
(информация
потреблений энергетических ресурсов
в
денежном
относится к
выражении
публичной
государственных и муниципальными
информации)
учреждениями
6
6.
Реестр
энергетических
Нет
договоров
(информация
(контрактов) заключенных в
относится к
публичной
инфо
течении года по государственным и
муниципальным учреждениям
7
7.
Сведения
Нет
о
рмации
снижении
Нет
потребления энергетических ресурсов
Нет
(информация
государственными и муниципальными
относится к
публичной
инфо
учреждениями
рмации
В соответствии с Перечнем сведений конфиденциального характера, утвержденным Указом
Президента РФ от 6 марта 1997 г. N 188.
2
Номер пункта и реквизиты нормативного правового акта, устанавливающего соответствие
обрабатываемой информации категории сведений конфиденциального характера.
89

=== ФАЙЛ: К-236-26 - Требования к содержанию, составу заявки на участие в закупке и инструкция по ее заполнению.docx | docs/0145200000426001424/К-236-26  - Требования к содержанию, составу заявки на участие в закупке и инструкция по ее заполнению.pdf
Требования к содержанию, составу заявки на участие в закупке и
инструкция по ее заполнению
I.
Требования к содержанию и составу заявки:
Для участия в закупке заявка на участие в закупке должна содержать
информацию и документы:
– предусмотренные подпунктами "а" - "л" пункта 1 части 1 статьи 43
Федерального закона №44-ФЗ; подтверждающие соответствие участника
закупки дополнительным требованиям, установленным в соответствии с
частью 2 или 2.1 (при наличии таких требований) статьи 31 Федерального
закон №44-ФЗ, и предусмотренные подпунктом "н" пункта 1 части 1 статьи
43 Федерального закона №44-ФЗ информация и документы, которые
подтверждают соответствие участника закупки установленным требованиям
(при наличии таких требований), содержится в извещении об осуществлении
закупки.
Такие информация и документы не включаются участником закупки в
заявку на участие в закупке, направляются (по состоянию на дату и время их
направления) заказчику оператором электронной площадки путем
информационного взаимодействия с единой информационной системой и из
реестра участников закупок, аккредитованных на электронной площадке.
Заявка на участие в закупке может не содержать предусмотренные
подпунктом "н" пункта 1 части 1 статьи 43 Федерального закона №44-ФЗ
сведения и документы в случае, если они содержатся в открытых и
общедоступных государственных реестрах, размещенных в информационнотелекоммуникационной сети "Интернет", и в заявку включена декларация о
соответствии участника закупки требованиям, установленным пунктом 1
части 1 статьи 31 Закона № 44-ФЗ, с указанием адреса сайта или страницы
сайта в информационно-телекоммуникационной сети "Интернет", на которых
размещены такие информация и документы;
– предусмотренные подпунктами "м", "о", "п" пункта 1 части 1 статьи
43 Федерального закона № 44-ФЗ;
– информацию и документы, подтверждающие предоставление
обеспечения заявки на участие в закупке, в форме электронных документов
или в форме электронных образов бумажных документов в случае, если
участник закупки является юридическим лицом, зарегистрированным на
территории государства - члена Евразийского экономического союза, за
исключением Российской Федерации, или физическим лицом, являющимся
гражданином государства - члена Евразийского экономического союза, за
исключением Российской Федерации, и предоставляет обеспечение заявок в
виде денежных средств.
Заявка на участие в электронном конкурсе состоит из второй и
третьей части.
Вторая часть должна содержать информацию и документы:
- предусмотренные подпунктами "м", "о", "п" пункта 1 части 1 статьи
43 Федерального закона №44-ФЗ;
- которые подтверждают соответствие участника закупки требованиям,
установленным пунктом 1 части 1 (при наличии таких требований) статьи 31
Федерального закона №44-ФЗ, и предусмотренное подпунктом "н" пункта 1
части 1 статьи 43 Федерального закона №44-ФЗ требование содержится в
извещении об осуществлении закупки (могут не включаться в заявку на
участие в закупке в случае, если указанные информация и документы
содержатся в открытых и общедоступных государственных реестрах,
размещенных в информационно-телекоммуникационной сети "Интернет", и в
такую заявку включена предусмотренная подпунктом "о" пункта 1 статьи 43
Федерального закона №44-ФЗ декларация о соответствии участника закупки
требованиям, установленным пунктом 1 части 1 статьи 31 закона);
- информация и документы, подтверждающие квалификацию
участника закупки, в случае установления критерия, предусмотренного
пунктом 4 части 1 статьи 32 Федерального закона №44-ФЗ и порядком
рассмотрения и оценки заявок на участие в конкурсе согласно Приложению
№4 «Порядок рассмотрения и оценки заявок на участие в конкурсе», в
соответствии. Отсутствие таких информации и документов не является
основанием для признания заявки не соответствующей требованиям
настоящего Федерального закона;
- документы, подтверждающие соответствие работы или услуги
требованиям, установленным в соответствии с законодательством
Российской Федерации (в случае, если в соответствии с законодательством
Российской Федерации установлены требования к товару, работе или услуге
и представление указанных документов предусмотрено извещением об
осуществлении закупки).
Третья часть должна содержать предложение участника закупки о
цене контракта или о сумме цен единиц товара, работы, услуги (в случае,
предусмотренном частью 24 статьи 22 Федерального закона №44-ФЗ).
II.
Инструкция по заполнению заявки:
Подача заявки на участие в закупке означает согласие участника
закупки, подавшего такую заявку, на выполнение работы, оказание услуги на
условиях, предусмотренных извещением об осуществлении закупки.
Характеристики предлагаемой участником закупки работы, услуги в заявке
на участие в закупке указанию не подлежат.
Язык заявки на участие в конкурсе — русский.
Входящие в заявку на участие документы, оригинал которых выданы
участнику закупки третьими лицами на ином языке, могут быть
представлены на этом языке при условии, что к ним будет прилагаться
перевод на русский язык. В случае противоречия оригинала и перевода
преимущество будет иметь перевод.
Порядок рассмотрения и оценки заявок на участие в конкурсе
представлен в приложении №4 «Порядок рассмотрения и оценки заявок на
участие в конкурсе».

=== ФАЙЛ: Приложение № 4. Порядок рассмотрения и оценки заявок на участие в конкурсе.docx | docs/0145200000426001424/Приложение № 4. Порядок рассмотрения и оценки заявок на участие в конкурсе.pdf
Приложение № 4
УТВЕРЖДАЮ
ДИРЕКТОР
ГОСУДАРСТВЕННОГО КАЗЕННОГО УЧРЕЖДЕНИЯ
ЛЕНИНГРАДСКОЙ ОБЛАСТИ
«ЦЕНТР ЭНЕРГОСБЕРЕЖЕНИЯ И
ПОВЫШЕНИЯ ЭНЕРГОЭФФЕКТИВНОСТИ
ЛЕНИНГРАДСКОЙ ОБЛАСТИ»
_________________ Н.А. Лазаревич
ПОРЯДОК
рассмотрения и оценки заявок на участие в конкурсе
I. Информация о заказчике и закупке товаров, работ, услуг для обеспечения государственных и
муниципальных нужд (далее - закупка)
Коды
Полное наименование
Место нахождения, телефон,
адрес электронной почты
Наименование объекта закупки
Государственное
казённое учреждение
Ленинградской области
"Центр энергосбережения и
повышения
энергоэффективности
Ленинградской области"
ИНН
Российская
Федерация, 191015, СанктПетербург, Калужский
переулок, дом 3, лит. А, 7812-3328488,
e-mail:
info@lenoblces.ru
по
ОКТМО
7841428446
784201001
КПП
40911000
Выполнение работ по развитию региональной
государственной информационной системы жилищнокоммунального хозяйства Ленинградской области в части развития
Подсистемы «Учет потребления коммунальных ресурсов
Ленинградской области»
II. Критерии и показатели оценки заявок на участие в закупке
№
1.
Критерий
оценки
Цена контракта,
сумма цен единиц
товара, работы,
услуги
Значимость
критерия
оценки,
процентов
Показатель
оценки
Значимость
показателя
оценки,
процентов
Показатель
оценки,
детализирующи
й показатель
оценки
30%
-
-
-
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
-
Формула оценки или шкала
оценки
Оценка заявок осуществляется по
формулам, предусмотренным пунктами
9,10 Положения «Об оценке заявок на
участие в закупке товаров, работ, услуг
для обеспечения государственных и
муниципальных нужд», утвержденного
Постановлением Правительства
Российской Федерации от 31.12.2021
№ 2604 «Об оценке заявок на участие в
закупке товаров, работ, услуг для
обеспечения государственных и
муниципальных нужд, внесении
изменений в пункт 4 постановления
Правительства Российской Федерации
от 20 декабря 2021 г. № 2369 и
признании утратившими силу
некоторых актов и отдельных
положений некоторых актов
Правительства Российской Федерации»
(далее - Положение).
1. Значение количества баллов
по критерию оценки "цена контракта,
сумма цен единиц товара, работы,
услуги", присваиваемое заявке, которая
подлежит
в
соответствии
с
Федеральным законом от 05.04.2013 №
44-ФЗ «О контрактной системе в сфере
закупок товаров, работ, услуг для
обеспечения
государственных
и
3
№
Критерий
оценки
Значимость
критерия
оценки,
процентов
Показатель
оценки
Значимость
показателя
оценки,
процентов
Показатель
оценки,
детализирующи
й показатель
оценки
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
Формула оценки или шкала
оценки
муниципальных нужд» (далее – Закон)
оценке по указанному критерию
оценки, (БЦi) определяется по одной из
следующих формул:
а) за исключением случаев,
предусмотренных подпунктом "б"
настоящего пункта и пунктом 2, - по
формуле:
 Ц -Ц 
БЦ i =100 -  i л  ×100,
 Цл 
где:
Цi - предложение участника закупки
о цене контракта, заявка (часть заявки)
которого подлежит в соответствии с
Законом оценке по критерию оценки
"цена контракта, сумма цен единиц
товара, работы, услуги" (далее - ценовое
предложение);
Цл
наилучшее
ценовое
предложение из числа предложенных в
соответствии с Законом участниками
закупки, заявки (части заявки) которых
подлежат оценке по критерию оценки
"цена контракта, сумма цен единиц
товара, работы, услуги";
б) в случае если по результатам
применения
формулы,
предусмотренной
подпунктом
"а"
настоящего пункта, при оценке хотя бы
4
№
Критерий
оценки
Значимость
критерия
оценки,
процентов
Показатель
оценки
Значимость
показателя
оценки,
процентов
Показатель
оценки,
детализирующи
й показатель
оценки
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
Формула оценки или шкала
оценки
одной заявки получено значение,
являющееся отрицательным числом,
значение
количества
баллов
по
критерию оценки "цена контракта,
сумма цен единиц товара, работы,
услуги" всем заявкам, подлежащим в
соответствии с Законом оценке по
указанному критерию оценки (БЦi),
определяется по формуле:
БЦ i = Ц нач - Ц i  
100
,
Ц нач - Ц л
где Цнач - начальная (максимальная)
цена контракта, или сумма начальных
(максимальных)
цен
каждого
контракта,
заключаемого
по
результатам проведения совместного
конкурса
(в
случае
проведения
совместного конкурса), или начальная
сумма цен единиц товаров, работ, услуг
(в случае, предусмотренном частью 24
статьи 22 Закона, в том числе при
проведении в таком случае совместного
конкурса).
2.
Если
при
проведении
процедуры подачи предложений о цене
контракта либо о сумме цен единиц
услуги (в случае, предусмотренном
5
№
Критерий
оценки
Значимость
критерия
оценки,
процентов
Показатель
оценки
Значимость
показателя
оценки,
процентов
Показатель
оценки,
детализирующи
й показатель
оценки
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
Формула оценки или шкала
оценки
частью 24 статьи 22 Закона) в
соответствии с Законом подано ценовое
предложение,
предусматривающее
снижение таких цены контракта либо
суммы цен ниже нуля, значение
количества баллов (БЦi) определяется в
следующем порядке:
а)
для
подлежащей
в
соответствии с Законом оценке заявки
участника
закупки,
ценовое
предложение
которого
не
предусматривает
снижение
цены
контракта либо суммы цен ниже нуля,
значение
количества
баллов
по
указанному критерию оценки (БЦi)
определяется по формуле:
 Ц + Цл 
БЦ i = 100 -  i
  100;
Ц
+
Ц
л 
 нач
б)
для
подлежащей
в
соответствии с Законом оценке заявки
участника
закупки,
ценовое
предложение
которого
предусматривает
снижение
цены
контракта либо суммы цен ниже нуля,
значение
количества
баллов
по
6
№
Критерий
оценки
Значимость
критерия
оценки,
процентов
Показатель
оценки
Значимость
показателя
оценки,
процентов
Показатель
оценки,
детализирующи
й показатель
оценки
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
Формула оценки или шкала
оценки
указанному критерию оценки (БЦi)
определяется по формуле:
 Ц л - Цi 
БЦ i =100 - 
 ×100.
Ц
+
Ц
л 
 нач
3. Оценка заявок по критерию
оценки "цена контракта, сумма цен
единиц товара, работы, услуги"
осуществляется в соответствии со
следующими требованиями:
а) заявкам, содержащим наилучшее
ценовое
предложение,
а
также
предложение,
равное
такому
наилучшему ценовому предложению,
присваивается 100 баллов;
б) значение Цл при применении
формулы,
предусмотренной
подпунктом "а" пункта 10 Положения, и
значения Цл и Цi при применении
формулы,
предусмотренной
подпунктом "б" пункта 10 Положения,
указываются без знака "минус";
в) применение показателей оценки по
критерию оценки "цена контракта,
сумма цен единиц товара, работы,
услуги" не допускается.
7
№
2.
Критерий
оценки
Квалификация
участников
закупки, в том
числе наличие у
них финансовых
ресурсов,
оборудования и
других
материальных
ресурсов на праве
собственности
или ином
законном
основании, опыта
работы,
связанного с
предметом
контракта, и
деловой
репутации,
специалистов и
иных работников
определенного
уровня
квалификации
Значимость
критерия
оценки,
процентов
70%
Показатель
оценки
Наличие у
участников
закупки
опыта
поставки
товара,
выполнения
работы,
оказания
услуги,
связанного с
предметом
контракта
Значимость
показателя
оценки,
процентов
100%
Показатель
оценки,
детализирующи
й показатель
оценки
Характеристика
квалификации
участников
закупки (общая
цена исполненных
участником
закупки
договоров)
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
100%
Формула оценки или шкала
оценки
Оценка заявок осуществляется по
формуле, предусмотренной
подпунктом е) пункта 20 Положения в
случае, если лучшим является
наибольшее значение
детализирующего показателя и
установлено предельное максимальное
значение детализирующего показателя.
Количество баллов, присваиваемое
заявке, которая подлежит в
соответствии с Федеральным законом
оценке по указанному критерию
оценки, (БХi) определяется по
формуле:
БХ i = Х i - Х min ×
100
;
Х пред
max - Х min
где:
Хi – значение детализирующего
показателя «общая цена исполненных
участником закупки договоров»,
содержащееся в предложении
участника закупки, заявка (часть
заявки) которого подлежит в
соответствии с Федеральным законом
оценке;
Хmin - минимальное значение
детализирующего показателя «общая
цена исполненных участником закупки
договоров», содержащееся в заявках
8
Критерий
оценки
№
Значимость
критерия
оценки,
процентов
Показатель
оценки
Значимость
показателя
оценки,
процентов
Показатель
оценки,
детализирующи
й показатель
оценки
Значимость
показателя,
детализирующе
го показатель
оценки,
процентов
Формула оценки или шкала
оценки
(частях заявок), подлежащих в
соответствии с Федеральным законом
оценке;
Х пред
max - предельное максимальное
значение детализирующего показателя
«общая цена исполненных участником
закупки договоров», установленное
Заказчиком.
(
Х пред
max = 31 029 618,35 руб.)
III. Отдельные положения о применении отдельных критериев оценки, показателей оценки и показателей оценки, детализирующих показатели
оценки, предусмотренных разделом II настоящего документа
№
Наименование критерия оценки, показателя оценки, показателя
оценки, детализирующего показатель оценки, при применении
которого устанавливается положение графой 3
Положение о применении критерия оценки, показателя оценки, показателя
оценки, детализирующего показатель оценки
1
2
3
1.
Критерий оценки «Цена контракта, сумма цен единиц товара,
работы, услуги»
Наилучшим является минимальное ценовое предложение.
Заявкам, содержащим наилучшее ценовое предложение, а также предложение,
равное такому наилучшему ценовому предложению, присваивается 100 баллов.
2.
Критерий оценки «Квалификация участников закупки»
Оценка заявки (части заявки) по критерию оценки определяется путем
суммирования среднего количества баллов, присвоенных всеми принимавшими
участие в ее рассмотрении и оценке членами комиссии по осуществлению
закупок по каждому показателю оценки, умноженного на значимость
соответствующего показателя оценки. При этом среднее количество баллов
определяется путем суммирования количества баллов, присвоенных каждым
членом комиссии по осуществлению закупок, и последующего деления на
9
1
2.1.
2
3
количество таких членов.
Критерий оценки «Квалификация участников закупки, в том
К оценке принимаются исполненные (за последние 5 лет, предшествующие
числе наличие у них финансовых ресурсов, оборудования и
дате окончания срока подачи заявок на участие в настоящем конкурсе)
других материальных ресурсов на праве собственности или
участником закупки с учетом правопреемства (в случае наличия в заявке
ином законном основании, опыта работы, связанного с
подтверждающего документа) гражданско-правовые договоры: исключительно
предметом контракта, и деловой репутации, специалистов и
контракты, заключенные и исполненные в соответствии с Федеральным законом
иных работников определенного уровня квалификации»
от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ,
услуг для обеспечения государственных и муниципальных нужд», и договоры,
Показатель оценки «Наличие у участников закупки опыта
заключенные и исполненные в соответствии с Федеральным законом от
выполнения работы, связанного с предметом контракта»
18.07.2011 № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами
юридических лиц», соответственно, предметы которых сопоставимы с
предметом контракта, заключаемого по результатам конкурса.
В соответствии с Положением об оценке заявок на участие в закупке товаров,
Детализирующий
показатель
оценки
«Общая
цена
работ,
услуг для обеспечения государственных и муниципальных нужд,
исполненных участником закупки договоров»
утвержденного постановлением Правительства Российской Федерации от 31
декабря 2021 г. № 2604 «Об оценке заявок на участие в закупке товаров, работ,
услуг для обеспечения государственных и муниципальных нужд, внесении
изменений в пункт 4 постановления Правительства Российской Федерации от 20
декабря 2021 г. № 2369 и признании утратившими силу некоторых актов и
отдельных положений некоторых актов Правительства Российской Федерации»
(далее - Положение) к оценке по детализирующему показателю оценки
«Общая цена исполненных участником закупки договоров» принимаются
исполненные договоры сопоставимые с предметом контракта, заключаемого по
результатам определения поставщика (подрядчика, исполнителя).
Под сопоставимым контрактом (договором) понимается исполненные (с
учетом правопреемства) гражданско-правовые договоры, предметом которых
являются работы/услуги, связанные с созданием и/или развитием и/или
сопровождением региональной информационной системы, имеющей интеграцию
с государственной информационной системой.
Для подтверждения наличия у участника закупки опыта выполнения работы,
оказания услуги, связанного с предметом контракта, необходимо предоставить
следующие документы:

исполненные контракты (договоры);

акты приемки выполненных работ, оказанных услуг, составленные при
исполнении таких контрактов (договоров), при условии исполнения требования
об уплате неустоек (штрафов, пеней) (в случае начисления неустоек). Последний
акт, составленный при исполнении договора, должен быть подписан не ранее
чем за 5 лет до даты окончания срока подачи заявок;
10
1
2
3

дополнительные соглашения, соглашение о расторжении (при наличии)
К оценке принимаются исключительно исполненные контракты (договоры),
при исполнении которых поставщиком (подрядчиком, исполнителем) исполнены
требования об уплате неустоек (штрафов, пеней) (в случае начисления неустоек).
К оценке принимаются документы, в случае их представления в заявке в
полном объеме и со всеми приложениями. Документы направляются в форме
электронных документов или в форме электронных образов бумажных
документов.
При оценке по показателю не будут учитываться договоры, по которым не
представлены документы, указанные в перечне документов, подтверждающих
наличие у участника закупки опыта выполнения работы, оказания услуги,
связанного с предметом контракта.
Если документы, подтверждающие наличие у участника закупки опыта
поставки товара, выполнения работы, оказания услуги, связанного с предметом
контракта, и информация о таких документах содержатся в открытых и
общедоступных государственных реестрах, размещенных в информационнотелекоммуникационной сети «Интернет», в том числе ведение которых
осуществляется в ЕИС с размещением указанных документов на официальном
сайте ЕИС в информационно-телекоммуникационной сети «Интернет», вместо
направления таких документов участник закупки вправе направить номер
реестровой записи из соответствующего реестра.
Отсутствие в заявке участника информации по детализирующему показателю
«Общая цена исполненных участником закупки договоров» не будет основанием
для признания заявки не соответствующей требованиям Федерального закона №
44-ФЗ и не влечет принятия решения об отклонении заявки. Такой участник
конкурса получает 0 баллов по данному детализирующему показателю.
В случае непредставления информации и подтверждающих документов по оцениваемому критерию (показателю), участнику не присваиваются
баллы по соответствующему критерию (показателю).
Итоговое количество баллов присваивается заявке путём суммирования баллов, присвоенных по критериям.

=== ФАЙЛ: Приложение № 3. Проект контракта.docx | docs/0145200000426001424/Приложение № 3. Проект контракта.pdf
Приложение № 3
Утверждаю
Директор государственного казенного
учреждения Ленинградской области
«Центр энергосбережения и повышения
энергоэффективности Ленинградской области»
____________ Лазаревич Н.А.
ГОСУДАРСТВЕННЫЙ КОНТРАКТ № __________
Выполнение работ по развитию региональной государственной информационной системы
жилищно-коммунального хозяйства Ленинградской области в части развития Подсистемы «Учет
потребления коммунальных ресурсов Ленинградской области»
г. Санкт-Петербург
«____»__________ _____ г.
Государственное казённое учреждение Ленинградской области "Центр энергосбережения и
повышения энергоэффективности Ленинградской области", в лице ___________________,
действующего на основании _______ (далее – «Заказчик»), с одной стороны, и
_______________________, в лице _________________, действующего на основании
_____________________ (далее - «Подрядчик»), с другой стороны, далее совместно именуемые
«Стороны», а по отдельности «Сторона», в соответствии с законодательством Российской
Федерации и иными нормативными правовыми актами о контрактной системе в сфере закупок, и
по результатам проведения открытого конкурса в электронной форме (электронного конкурса),
объявленного Извещением от «___» _________ __ г. № ________________ (идентификационный
код закупки № 262784142844678420100100160016201246), на основании Протокола от «___»
_________ __ г. № ________________, заключили настоящий государственный контракт (далее –
«Контракт») о нижеследующем:
1.
Предмет Контракта
1.1.
Подрядчик обязуется собственными и (или) привлеченными силами, своевременно
выполнить на условиях настоящего Контракта Выполнение работ по развитию
региональной государственной информационной системы жилищно-коммунального
хозяйства Ленинградской области в части развития Подсистемы «Учет потребления
коммунальных ресурсов Ленинградской области» (далее – «работы») в пользу Заказчика и
сдать результат работ Заказчику, а Заказчик обязуется принять и оплатить результат работ.
1.2.
Состав и объем работ определяется Спецификацией (Приложение № 2 Контракта), работы
осуществляются в соответствии с Описанием объекта закупки (Приложение № 1
Контракта).
1.3.
Место выполнения работ:
- Санкт-Петербург и Ленинградская область, Подсистема развернута на аппаратных
мощностях ЦОД Правительства Ленинградской области по адресу: г. Санкт-Петербург,
Выборгское шоссе, д. 503, корп. 12;
- ГКУ ЛО «ЦЭПЭ ЛО»: Санкт-Петербург г., муниципальный округ Смольнинское
вн.тер.г., Калужский пер., дом 3, литера А;
- Комитет по топливно-энергетическому комплексу Ленинградской области: г. СанктПетербург, ул. Смольного, д. 3. (далее – «место выполнения работ»).
2.
Цена Контракта (Предложение о цене за право заключения Контракта)
1
2.1.
Цена Контракта (Предложение о цене за право заключения Контракта) и валюта платежа
устанавливаются в российских рублях.
2.2.
Цена Контракта является твердой, не может изменяться в ходе исполнения Контракта, за
исключением случаев, установленных Контрактом и (или) предусмотренных
законодательством Российской Федерации.
Цена контракта (Предложение о цене за право заключения Контракта) составляет
_______________(________) рублей__ копеек,
в случае, если Подрядчик применяет общую систему налогообложения:
в том числе НДС (__%) _______________(________) рублей__ копеек (НДС не облагается
на основании ______________ Налогового кодекса Российской Федерации и ________)
2.3.
Сумма, подлежащая уплате Заказчиком юридическому лицу или физическому лицу, в том
числе зарегистрированному в качестве индивидуального предпринимателя, уменьшается
на размер налогов, сборов и иных обязательных платежей в бюджеты бюджетной системы
Российской Федерации, связанных с оплатой Контракта, если в соответствии с
законодательством Российской Федерации о налогах и сборах такие налоги, сборы и иные
обязательные платежи подлежат уплате в бюджеты бюджетной системы Российской
Федерации Заказчиком.
2.4.
В цену Контракта включены все расходы Подрядчика, необходимые для осуществления им
своих обязательств по Контракту в полном объеме и надлежащего качества, в том числе
все подлежащие к уплате налоги, сборы и другие обязательные платежи, и иные расходы,
связанные с выполнением работ.
2.5.
По согласованию Сторон в ходе исполнения Контракта допускается снижение цены
Контракта без изменения предусмотренного Контрактом объема работ, качества
выполняемых работ и иных условий Контракта.
2.6.
Оплата по Контракту производится в следующем порядке:
2.7.
Оплата производится в безналичном порядке путем перечисления денежных средств на
счет Подрядчика. Датой оплаты считается дата списания денежных средств со счета
Заказчика.
2.8.
Источник финансирования Контракта:
- Областной бюджет Ленинградской области
на 2026 год
________ (___________) рубля __ копеек
2.9.
Авансовые платежи по Контракту не предусмотрены.
2.10.
Расчет за выполненные работы осуществляется в течение 7 (Семи) рабочих дней со дня
подписания Заказчиком документа, подтверждающего приемку выполненных работ.
2.11.
В случае уменьшения Заказчику соответствующими государственными органами в
установленном порядке ранее утвержденных лимитов бюджетных обязательств,
приводящего к невозможности исполнения Заказчиком обязательств по Контракту, о чем
Заказчик уведомляет Подрядчика, Стороны согласовывают в соответствии с
законодательством Российской Федерации новые условия Контракта, в том числе по цене
и (или) срокам исполнения контракта и (или) объему выполняемой работы.
2.12.
Заказчик по согласованию с Подрядчиком в ходе исполнения Контракта вправе изменить
не более чем на 10% предусмотренный Контрактом объем работ при изменении
потребности в работах, на выполнение которых заключен Контракт. При этом по
соглашению Сторон допускается изменение с учетом положений бюджетного
законодательства
Российской
Федерации
цены
Контракта
пропорционально
дополнительному объему работ исходя из установленной в Контракте цены единицы
работы, но не более чем на 10% цены Контракта. При уменьшении предусмотренного
2
Контрактом объема работ Стороны Контракта обязаны уменьшить цену Контракта исходя
из цены единицы работы.
3.
Права и обязанности Сторон
3.1.
Заказчик имеет право:
3.1.1.
Проверять в любое время ход и качество выполняемой Подрядчиком и его
субподрядчиками работы по Контракту, оказывать консультативную и иную помощь
Подрядчику без вмешательства в его оперативно-хозяйственную деятельность;
3.1.2.
Отказаться от оплаты работы в случае несоответствия результатов выполненной работы
требованиям, установленным Контрактом;
3.1.3.
По согласованию с Подрядчиком изменить объем выполняемых по Контракту работ в
соответствии с условиями Контракта;
3.1.4.
Досрочно принять и оплатить работы в соответствии с условиями Контракта;
3.1.5.
Проводить экспертизу соответствия качества выполняемых работ требованиям,
установленным Контрактом, своими силами или путем привлечения экспертов,
экспертных организаций;
3.1.6.
Принять решение об одностороннем отказе от исполнения настоящего Контракта в
соответствии с гражданским законодательством Российской Федерации;
3.1.7.
Осуществлять иные права, предусмотренные Контрактом и (или) законодательством
Российской Федерации.
3.2.
Заказчик обязан:
3.2.1.
Обеспечить приемку представленных Подрядчиком результатов работы по Контракту;
3.2.2.
Оплатить выполненную по Контракту работу после подписания Сторонами документа,
подтверждающего приемку выполненных работ;
3.2.3.
Принять решение об одностороннем отказе от исполнения Контракта в случаях,
установленных Федеральным законом от 05.04.2013 № 44-ФЗ «О контрактной системе в
сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных
нужд» (далее – «Федеральный закон о контрактной системе»);
3.2.4.
Требовать возмещения неустойки и (или) убытков, причиненных по вине Подрядчика.
3.3.
Подрядчик вправе:
3.3.1.
Требовать от Заказчика приемки результатов выполнения работы;
3.3.2.
Требовать от Заказчика оплаты принятой без замечаний работы;
3.3.3.
Запрашивать у Заказчика информацию, необходимую для выполнения Контракта;
3.3.4.
Требовать возмещения убытков, причиненных Подрядчику по вине Заказчика в ходе
исполнения Контракта;
3.3.5.
Привлечь к исполнению своих обязательств других лиц (субподрядчиков).
3.4.
Подрядчик обязан:
3.4.1.
Без увеличения цены выполнить работу в соответствии с условиями Контракта и передать
Заказчику ее результаты по документу, подтверждающего приемку выполненных работ;
3.4.2.
Своими силами и за свой счет, в срок, определенный Заказчиком, устранять допущенные
недостатки в выполненной работе или иные отступления от условий Контракта;
3.4.3.
Немедленно известить Заказчика и до получения от него указаний приостановить работы
при обнаружении:
- возможных неблагоприятных для Заказчика последствий выполнения его указаний о
способе исполнения работы;
3
- иных обстоятельств, угрожающих годности или прочности результатов выполняемой
работы либо создающих невозможность ее завершения в срок;
3.4.4.
Предоставлять по запросам Заказчика иную информацию о ходе исполнения Контракта;
3.4.5.
Соблюдать действующие у Заказчика правила внутреннего трудового распорядка,
пожарной безопасности, пропускной и внутриобъектовый режимы. Обеспечить в ходе
выполнения работ соблюдение необходимых мероприятий по охране труда и
экологической безопасности;
3.4.6.
Предоставить гарантию качества на результаты выполненных работ гарантийный срок на
выполненные работы: 12 месяцев. гарантийный срок начинает исчисляться с момента
подписания документа о приемке. с даты подписания Подрядчиком и Заказчиком
документа о приемке выполненных работ. Гарантия осуществляется путем безвозмездного
устранения Подрядчиком недостатков выполненных работ, выявленных в течение
гарантийного срока, установленного Контрактом;
3.4.7.
Сохранять конфиденциальность информации, относящейся к ходу исполнения Контракта и
полученным результатам;
3.4.8.
Предоставлять своевременно достоверную информацию о ходе исполнения своих
обязательств, в том числе о сложностях, возникающих при исполнении Контракта;
3.4.9.
Подрядчик, не являющийся субъектом малого предпринимательства, или социально
ориентированной некоммерческой организацией, обязан привлекать к исполнению
Контракта субподрядчиков из числа субъектов малого предпринимательства, социально
ориентированных некоммерческих организаций (далее – «субподрядчики») в объеме 25%
от цены Контракта.
3.4.9.1. В срок не более 5 (Пяти) рабочих дней со дня заключения договора с субподрядчиком
представить Заказчику:
(а)
декларацию о принадлежности субподрядчика к субъектам малого
предпринимательства, социально ориентированной некоммерческой организации,
составленную в простой письменной форме, подписанную руководителем (иным
уполномоченным лицом) субъекта малого предпринимательства, социально
ориентированной некоммерческой организации и заверенную печатью (при
наличии печати);
(б)
копию договора (договоров), заключенного с субподрядчиком, заверенную
Подрядчиком.
3.4.9.2. В случае замены субподрядчика на этапе исполнения Контракта на другого субподрядчика
представлять Заказчику документы, указанные в подпункте 3.4.9.1 Контракта, в течение 5
(Пяти) дней со дня заключения договора с новым субподрядчиком.
3.4.9.3. В течение 10 (Десяти) рабочих дней со дня оплаты Подрядчиком выполненных
обязательств по договору с субподрядчиком представлять Заказчику следующие
документы:
(а)
копии документов о приемке выполненной работы, которые являются предметом
договора, заключенного между Подрядчиком и привлеченным им субподрядчиком;
(б)
копии платежных поручений, подтверждающих перечисление денежных средств
Подрядчиком субподрядчику, - в случае если договором, заключенным между
Подрядчиком и привлеченным им субподрядчиком, предусмотрена оплата
выполненных
обязательств
до
срока
оплаты
выполненных
работ,
предусмотренного Контрактом, заключенным с Заказчиком (в ином случае
указанный документ представляется Заказчику дополнительно в течение 5 (Пяти)
дней со дня оплаты Подрядчиком обязательств, выполненных субподрядчиком).
3.4.9.4. Оплачивать поставленные субподрядчиком товары, выполненные работы (ее результаты),
оказанные услуги, отдельные этапы исполнения договора, заключенного с таким
субподрядчиком, в течение 7 (Семи) рабочих дней с даты подписания Подрядчиком
4
документа о приемке выполненной работы (ее результатов), отдельных этапов исполнения
договора.
3.4.9.5. Нести гражданско-правовую ответственность перед Заказчиком за неисполнение или
ненадлежащее исполнение условия о привлечении к исполнению контрактов
субподрядчиков, в том числе:
(а)
за представление документов, указанных в подпунктах 3.4.9.1 – 3.4.9.3 Контракта,
содержащих недостоверные сведения, либо их непредставление или представление
таких документов с нарушением установленных сроков;
(б)
за непривлечение субподрядчиков в объеме, установленном в Контракте.
3.4.10. Возвратить сумму излишне полученных денежных средств в случае установления
контролирующими органами фактов оплаты Заказчиком работ сверх фактически
выполненного объема работ, использования при выполнении работ материалов, не
предусмотренных сметами (техническими заданиями) к Контракту, изменения способа
выполнения работ при отсутствии соответствующих согласований с Заказчиком;
3.4.11. Выполнять иные обязанности, предусмотренные Контрактом.
4.
Сроки выполнения работ по Контракту
4.1.
Подрядчик приступает к выполнению работ с момента заключения Контракта Сторонами.
4.2.
Работы должны быть закончены в срок не позднее «14» декабря 2026 г.
4.3.
Подрядчик по согласованию с Заказчиком может досрочно сдать выполненные работы.
Заказчик вправе досрочно принять и оплатить такие работы в соответствии с условиями
Контракта.
4.4.
В случае если в пункте 14.1 Контракта указана дата, при наступлении которой
обязательства Сторон прекращаются, за исключением обязательств по оплате
выполненных и принятых Заказчиком работ, гарантийных обязательств, обязательств по
возмещению убытков и выплате неустойки, Стороны после наступления указанной даты
не вправе требовать исполнения Контракта.
5.
Срок исполнения Контракта
5.1.
В соответствии с положениями части 1 статьи 94 Федерального закона о контрактной
системе в Контракте устанавливаются сроки исполнения Контракта, включающие в себя, в
том числе, приемку и оплату Заказчиком выполненных работ по Контракту.
5.2.
Дата начала исполнения Контракта: с даты заключения Контракта.
5.3.
Дата окончания исполнения Контракта: «31» декабря 2026 г.
6.
Порядок сдачи и приемки работ
6.1.
Приемка работ на соответствие их объема и качества требованиям, установленным в
Контракте, производится за весь предусмотренный Контрактом объем работ.
6.2.
Подрядчик предоставляет счет-фактуру (при необходимости) в соответствии с налоговым
законодательством Российской Федерации.
6.3.
Для проверки предоставленных Подрядчиком результатов выполненных работ,
предусмотренных Контрактом, в части их соответствия условиям Контракта Заказчик
обязан провести экспертизу. Экспертиза результатов, предусмотренных Контрактом,
может проводиться Заказчиком своими силами или к ее проведению могут привлекаться
эксперты, экспертные организации на основании контрактов, заключенных в соответствии
с Федеральным законом о контрактной системе.
6.4.
Для проведения экспертизы выполненной работы эксперты, экспертные организации
имеют право запрашивать у Заказчика и Подрядчика дополнительные материалы,
5
относящиеся к условиям исполнения Контракта и отдельным этапам исполнения
Контракта. В случае, если по результатам такой экспертизы установлены нарушения
требований Контракта, не препятствующие приемке выполненной работы, в заключении
могут содержаться предложения об устранении данных нарушений, в том числе с
указанием срока их устранения.
6.5.
По решению Заказчика для приемки выполненной работы, результатов отдельного этапа
исполнения Контракта может создаваться приемочная комиссия. В случае создания
приемочной комиссии приемка результата исполнения Контракта осуществляется
приемочной комиссией и утверждается Заказчиком.
6.6.
В случае установления Заказчиком требования об обеспечении гарантийных обязательств
оформление документа о приемке выполненной работы (ее результатов) осуществляется
после предоставления Подрядчиком такого обеспечения в соответствии с Федеральным
законом о контрактной системе в порядке и в сроки, которые установлены разделом 8
настоящего Контракта.
6.7.
При исполнении Контракта Подрядчик в течение 2 (Двух) рабочих дней после выполнения
работ формирует с использованием единой информационной системы (далее – «ЕИС»),
подписывает усиленной электронной подписью лица, имеющего право действовать от
имени Подрядчика, и размещает в ЕИС документ о приемке в соответствии с едиными
формами документов, установленных Правительством Российской Федерации, который
должен содержать:
(а)
включенные в Контракт идентификационный код закупки, наименование, место
нахождения Заказчика, наименование объекта закупки, место выполнения работы,
информацию о Подрядчике, единицу измерения поставленного товара (при
осуществлении закупки товара при выполнении работ), выполненной работы;
(б)
наименование выполненной работы;
(в)
информацию об объеме выполненной работы;
(г)
стоимость
исполненных
Подрядчиком
обязательств,
предусмотренных
Контрактом, с указанием цены за единицу поставленного товара (при
осуществлении закупки товара при выполнении работ), выполненной работы.
6.8.
Датой поступления Заказчику документа о приемке, подписанного Подрядчиком,
считается дата размещения такого документа в ЕИС в соответствии с часовой зоной, в
которой расположен Заказчик;
6.9.
В срок не позднее 10 (Десяти) рабочих дней, следующих за днем поступления документа о
приемке, Заказчик (за исключением случая создания приемочной комиссии) осуществляет
одно из следующих действий:
6.10.
(а)
подписывает усиленной электронной подписью лица, имеющего право действовать
от имени Заказчика, и размещает в ЕИС документ о приемке;
(б)
формирует с использованием ЕИС, подписывает усиленной электронной подписью
лица, имеющего право действовать от имени Заказчика, и размещает в ЕИС
мотивированный отказ от подписания документа о приемке с указанием причин
такого отказа.
В случае создания приемочной комиссии не позднее 20 (Двадцати) рабочих дней,
следующих за днем поступления Заказчику документа о приемке, члены приемочной
комиссии подписывают усиленными электронными подписями поступивший документ о
приемке или формируют с использованием ЕИС, подписывают усиленными электронными
подписями мотивированный отказ от подписания документа о приемке с указанием
причин такого отказа. При этом, если приемочная комиссия включает членов, не
являющихся работниками Заказчика, допускается осуществлять подписание документа о
приемке, составление мотивированного отказа от подписания документа о приемке,
подписание такого отказа без использования усиленных электронных подписей и ЕИС.
6
6.11.
После подписания членами приемочной комиссии документа о приемке или
мотивированного отказа от подписания документа о приемке Заказчик подписывает
документ о приемке или мотивированный отказ от подписания документа о приемке
усиленной электронной подписью лица, имеющего право действовать от имени Заказчика,
и размещает их в ЕИС. Если члены приемочной комиссии не использовали усиленные
электронные подписи и ЕИС, Заказчик прилагает подписанные ими документы в форме
электронных образов бумажных документов.
6.12.
Датой поступления Подрядчику документа о приемке, мотивированного отказа от
подписания документа о приемке считается дата размещения документа о приемке или
мотивированного отказа в ЕИС в соответствии с часовой зоной, в которой расположен
Подрядчик.
6.13.
В случае получения мотивированного отказа от подписания документа о приемке
Подрядчик вправе устранить причины, указанные в таком мотивированном отказе, и
направить Заказчику документ о приемке в порядке, предусмотренном настоящим
разделом Контракта.
6.14.
Датой приемки выполненной работы считается дата размещения в ЕИС документа о
приемке, подписанного Заказчиком.
6.15.
Внесение исправлений в документ о приемке осуществляется путем формирования,
подписания усиленными электронными подписями лиц, имеющих право действовать от
имени Подрядчика, Заказчика, и размещения в ЕИС исправленного документа о приемке.
Допускается как полная, так и частичная приемка работ по Контракту.
В случае, если Заказчиком осуществлена частичная приемка выполненных работ по
Контракту, в документе о приемке, направленном Подрядчиком и подписываемом
Заказчиком, отражается информация о фактически принятом объеме работ. После
получения документа о приемке, подписанного Заказчиком с условием о частичной
приемке, Подрядчик формирует с использованием ЕИС, подписывает усиленной
электронной подписью лица, имеющего право действовать от имени Подрядчика, и
размещает в ЕИС корректировочный документ о приемке, содержащий сведения о
фактически принятом объеме работ. Заказчик рассматривает и подписывает
корректировочный документ о приемке в порядке и сроки, предусмотренные настоящим
разделом Контракта.
После выполнения оставшегося объема работ Подрядчик в порядке и сроки,
предусмотренные настоящим разделом Контракта, формирует новый документ о приемке.
Заказчик рассматривает и подписывает указанный новый документ о приемке в порядке и
сроки, предусмотренные настоящим разделом Контракта.
6.16.
При исполнении Контракта по согласованию Заказчика с Подрядчиком допускается замена
предусмотренной контрактом работы на работу, функциональные, технические и
качественные характеристики, эксплуатационные характеристики которой аналогичны или
улучшены по сравнению с характеристиками, предусмотренными описанием объекта
закупки.
7.
Обеспечение исполнения Контракта
7.1.
Подрядчик предоставляет обеспечение исполнения Контракта в размере 10% от начальной
(максимальной) цены Контракта, что составляет 620 592 (Шестьсот двадцать тысяч
пятьсот девяносто два) рубля 36 копеек.
В случае если Контрактом предусмотрены отдельные этапы его исполнения, размер
обеспечения исполнения Контракта в ходе исполнения Контракта подлежит уменьшению в
порядке и случаях, которые предусмотрены пунктами 7.4 и 7.5 Контракта.
7.2.
Исполнение Контракта обеспечивается предоставлением независимой гарантии,
соответствующей требованиям статьи 45 Федерального закона о контрактной системе, или
внесением денежных средств на указанный Заказчиком счет, на котором в соответствии с
7
законодательством Российской Федерации учитываются операции со средствами,
поступающими Заказчику:
Номер лицевого счета Заказчика в УФК: 06367978005;
Номер казначейского счета Заказчика: 03222643410000004500;
Наименование УФК: УФК по Ленинградской области;
Номер единого казначейского счета: 40102810745370000098;
БИК: 044030098.
Способ обеспечения исполнения Контракта, срок действия независимой гарантии
определяются в соответствии с требованиями Федерального закона о контрактной системе
Подрядчиком самостоятельно.
Срок действия независимой гарантии должен превышать предусмотренный Контрактом
срок исполнения обязательств, которые должны быть обеспечены такой независимой
гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии
со статьей 95 Федерального закона о контрактной системе.
7.3.
В ходе исполнения Контракта Подрядчик вправе изменить способ обеспечения исполнения
Контракта и (или) предоставить Заказчику взамен ранее предоставленного обеспечения
исполнения Контракта новое обеспечение исполнения Контракта, размер которого может
быть уменьшен в порядке и случаях, которые предусмотрены пунктами 7.4 и 7.5
Контракта.
7.4.
Размер обеспечения исполнения Контракта уменьшается посредством направления
Заказчиком информации об исполнении Подрядчиком обязательств по выполнению работ
или об исполнении им отдельного этапа исполнения Контракта и стоимости исполненных
обязательств для включения в реестр контрактов, предусмотренный статьей 103
Федерального закона о контрактной системе (далее – «реестр контрактов»). Уменьшение
размера обеспечения исполнения Контракта производится пропорционально стоимости
исполненных обязательств, приемка и оплата которых осуществлены в порядке и сроки,
которые предусмотрены Контрактом. В случае, если обеспечение исполнения Контракта
осуществляется путем предоставления независимой гарантии, требование Заказчика об
уплате денежных сумм по этой гарантии может быть предъявлено в размере не более
размера обеспечения исполнения Контракта, рассчитанного Заказчиком на основании
информации об исполнении Контракта, размещенной в реестре контрактов. В случае, если
обеспечение исполнения Контракта осуществляется путем внесения денежных средств на
счет, указанный Заказчиком, по заявлению Подрядчика ему возвращаются Заказчиком в
установленный в пункте 7.14 Контракта срок денежные средства в сумме, на которую
уменьшен размер обеспечения исполнения Контракта, рассчитанный Заказчиком на
основании информации об исполнении Контракта, размещенной в реестре контрактов.
7.5.
Предусмотренное пунктами 7.1 и 7.3 Контракта уменьшение размера обеспечения
исполнения Контракта осуществляется при условии отсутствия не исполненных
Подрядчиком требований об уплате неустоек (штрафов, пеней), предъявленных
Заказчиком в соответствии с разделом 9 Контракта, а также приемки Заказчиком
выполненной работы, результатов отдельного этапа выполнения работ в объеме
выплаченного аванса (если Контрактом предусмотрена выплата аванса) либо в объеме,
превышающем выплаченный аванс (если в соответствии с законодательством Российской
Федерации расчеты по Контракту в части выплаты аванса подлежат казначейскому
сопровождению). Такое уменьшение не допускается в случаях, определенных
Правительством Российской Федерации в целях обеспечения обороноспособности и
безопасности государства, защиты здоровья, прав и законных интересов граждан
Российской Федерации.
7.6.
Изменение существенных условий Контракта осуществляется при условии предоставления
Подрядчиком в соответствии с Федеральным законом о контрактной системе обеспечения
исполнения Контракта, если такие изменения влекут возникновение новых обязательств
Подрядчика, не обеспеченных ранее предоставленным обеспечением исполнения
8
Контракта, и, если при определении Подрядчика требование обеспечения исполнения
Контракта установлено в соответствии со статьей 96 Федерального закона о контрактной
системе. При этом:
1) размер обеспечения может быть уменьшен в порядке и случаях, предусмотренных
частями 7 - 7.3 статьи 96 Федерального закона о контрактной системе;
2) обеспечение исполнения Контракта может быть предоставлено путем внесения
соответствующих изменений в условия ранее предоставленной Заказчику независимой
гарантии;
3) если обеспечение исполнения Контракта осуществляется путем предоставления новой
независимой гарантии, возврат Заказчиком ранее предоставленной ему независимой
гарантии предоставившему ее гаранту не осуществляется, взыскание по ней не
производится, Заказчик признается отказавшимся от своих прав по ранее предоставленной
независимой гарантии, обязательство гаранта перед Заказчиком по ранее предоставленной
независимой гарантии прекращается с момента выдачи новой независимой гарантии;
4) если при увеличении в соответствии со статьей 95 Федерального закона о контрактной
системе цены Контракта обеспечение исполнения Контракта осуществляется путем
внесения денежных средств, Подрядчик вносит на счет, на котором в соответствии с
законодательством Российской Федерации учитываются операции со средствами,
поступающими Заказчику, денежные средства в размере, пропорциональном стоимости
новых обязательств Подрядчика.
7.7.
В случае уменьшения цены Контракта Заказчик возвращает Подрядчику денежные
средства в размере, пропорциональном размеру такого уменьшения цены Контракта.
7.8.
В случае изменения (уменьшения) срока исполнения Контракта по соглашению сторон
устанавливается новый срок возврата Заказчиком Подрядчику денежных средств,
внесенных в качестве обеспечения исполнения Контракта.
7.9.
В случае отзыва в соответствии с законодательством Российской Федерации у банка,
предоставившего независимую гарантию в качестве обеспечения исполнения Контракта,
лицензии на осуществление банковских операций, Подрядчик обязан предоставить новое
обеспечение исполнения Контракта не позднее одного месяца со дня надлежащего
уведомления Заказчиком Подрядчика о необходимости предоставить соответствующее
обеспечение.
За каждый день просрочки исполнения Подрядчиком обязательства, предусмотренного
настоящим пунктом, начисляется пеня в размере, определенном в порядке, установленном
в соответствии с разделом 9 Контракта.
Размер нового обеспечения исполнения Контракта может быть уменьшен в порядке и
случаях, которые предусмотрены пунктами 7.1, 7.3, 7.4 и 7.5 Контракта.
7.10.
Уменьшение в соответствии с пунктами 7.1 и 7.3 Контракта размера обеспечения
исполнения Контракта, предоставленного в виде независимой гарантии, осуществляется
Заказчиком путем отказа от части своих прав по этой гарантии. При этом датой такого
отказа признается дата включения предусмотренной пунктом 7.4 Контракта информации в
соответствующий реестр контрактов.
7.11.
В случае предоставления нового обеспечения исполнения Контракта в соответствии с
пунктом 7.3 Контракта возврат независимой гарантии Заказчиком гаранту,
предоставившему указанную независимой гарантию, не осуществляется, взыскание по ней
не производится.
7.12.
В случае, если обеспечением исполнения Контракта является внесение денежных средств
на указанный Заказчиком счет, Заказчик при неисполнении или ненадлежащем
исполнении Подрядчиком любого из обязательств по Контракту вправе удержать
денежные средства.
9
7.13.
В случае, если обеспечением исполнения Контракта является независимая гарантия,
Заказчик при неисполнении или ненадлежащем исполнении Подрядчиком любого из
обязательств по Контракту вправе потребовать у гаранта уплаты денежной суммы.
7.14.
Денежные средства, внесенные Подрядчиком в качестве обеспечения исполнения
Контракта, в том числе часть этих денежных средств в случае уменьшения размера
обеспечения исполнения Контракта в соответствии с пунктами 7.1, 7.3 и 7.4 Контракта,
возвращаются Подрядчику в срок не позднее 30 (Тридцати) дней с даты исполнения
Подрядчиком обязательств, предусмотренных Контрактом (если такая форма обеспечения
исполнения Контракта применяется Подрядчиком).
7.15.
В случае если предложенная в заявке Подрядчика цена снижена на двадцать пять и более
процентов по отношению к начальной (максимальной) цене контракта, Подрядчик
предоставляет обеспечение исполнения Контракта с учетом положений статьи 37
Федерального закона о контрактной системе.
7.16.
Положения настоящего раздела Контракта не применяются в случае заключения
Контракта с участником закупки, который является казенным учреждением.
8.
Обеспечение гарантийных обязательств
8.1.
До оформления документа о приемке (за исключением отдельного этапа исполнения
Контракта) выполненных работ Подрядчик предоставляет обеспечение гарантийных
обязательств в размере 10% от начальной (максимальной) цены Контракта, что составляет
620 592 (Шестьсот двадцать тысяч пятьсот девяносто два) рубля 36 копеек.
8.2.
Гарантийные обязательства обеспечиваются предоставлением независимой гарантии,
соответствующей требованиям статьи 45 Федерального закона о контрактной системе, или
внесением денежных средств на указанный Заказчиком счет, на котором в соответствии с
законодательством Российской Федерации учитываются операции со средствами,
поступающими Заказчику:
Номер лицевого счета Заказчика в УФК: 06367978005;
Номер казначейского счета: 03222643410000004500;
Наименование УФК: УФК по Ленинградской области;
Номер единого казначейского счета: 40102810745370000098;
БИК: 044030098.
Способ обеспечения гарантийных обязательств, срок действия независимой гарантии
определяются в соответствии с требованиями Федерального закона о контрактной системе
Подрядчиком самостоятельно.
Срок действия независимой гарантии должен превышать предусмотренный Контрактом
срок исполнения обязательств, которые должны быть обеспечены такой независимой
гарантией, не менее чем на 1 (Один) месяц, в том числе в случае его изменения в
соответствии со статьей 95 Федерального закона о контрактной системе.
8.3.
Подрядчик вправе изменить способ обеспечения гарантийных обязательств и (или)
предоставить Заказчику взамен ранее предоставленного обеспечения гарантийных
обязательств новое обеспечение гарантийных обязательств.
8.4.
Положения настоящего раздела Контракта не применяются в случае заключения
Контракта с участником закупки, который является казенным учреждением.
9.
Ответственность Сторон
9.1.
За неисполнение или ненадлежащее исполнение обязательств по Контракту Стороны несут
ответственность в соответствии с действующим законодательством Российской
Федерации.
10
Сторона освобождается от уплаты неустойки (штрафов, пеней), если докажет, что
неисполнение или ненадлежащее исполнение обязательства, предусмотренного
Контрактом, произошло вследствие непреодолимой силы или по вине другой Стороны.
Общая сумма начисленных штрафов за неисполнение или ненадлежащее исполнение
Подрядчиком обязательств, предусмотренных Контрактом, не может превышать цену
Контракта.
Общая сумма начисленных штрафов за ненадлежащее исполнение Заказчиком
обязательств, предусмотренных Контрактом, не может превышать цену Контракта.
9.2.
В случае просрочки исполнения Заказчиком обязательств, предусмотренных Контрактом, а
также в иных случаях неисполнения или ненадлежащего исполнения Заказчиком
обязательств, предусмотренных Контрактом, Подрядчик вправе потребовать уплаты
неустоек (штрафов, пеней).
9.3.
Пеня начисляется за каждый день просрочки исполнения Заказчиком обязательства,
предусмотренного Контрактом, начиная со дня, следующего после дня истечения
установленного Контрактом срока исполнения обязательства. При этом размер пени
устанавливается в размере одной трехсотой действующей на дату уплаты пеней ключевой
ставки Центрального банка Российской Федерации от не уплаченной в срок суммы.
9.4.
Штрафы начисляются за ненадлежащее исполнение Заказчиком обязательств,
предусмотренных Контрактом, за исключением просрочки исполнения обязательств,
предусмотренных Контрактом.
9.4.1.
Размер штрафа по каждому факту неисполнения Заказчиком обязательств,
предусмотренных Контрактом, за исключением просрочки исполнения обязательств,
предусмотренных Контрактом, устанавливается в соответствии с постановлением
Правительства Российской Федерации от 30.08.2017 № 1042 «Об утверждении Правил
определения размера штрафа, начисляемого в случае ненадлежащего исполнения
заказчиком, неисполнения или ненадлежащего исполнения поставщиком (подрядчиком,
исполнителем) обязательств, предусмотренных контрактом (за исключением просрочки
исполнения обязательств заказчиком, поставщиком (подрядчиком, исполнителем), о
внесении изменений в постановление Правительства Российской Федерации от 15.05.2017
№ 570 и признании утратившим силу постановления Правительства Российской
Федерации от 25.11.2013 № 1063» (далее – «Постановление № 1042») в следующем
порядке:
(а)
1 000 рублей, если цена Контракта не превышает 3 млн. рублей (включительно).
(б)
5 000 рублей, если цена Контракта составляет от 3 млн. рублей до 50 млн. рублей
(включительно).
9.5.
В случае просрочки исполнения Подрядчиком обязательств (в том числе гарантийного
обязательства), предусмотренных Контрактом, а также в иных случаях неисполнения или
ненадлежащего исполнения Подрядчиком обязательств, предусмотренных Контрактом,
Заказчик направляет Подрядчику требование об уплате неустоек (штрафов, пеней).
9.6.
Пеня начисляется за каждый день просрочки исполнения Подрядчиком обязательства,
предусмотренного Контрактом, начиная со дня следующего за днем истечения
установленного Контрактом срока исполнения обязательства, в размере одной трехсотой
действующей на дату уплаты пеней ключевой ставки Центрального банка Российской
Федерации от цены Контракта, уменьшенной на сумму, пропорциональную объему
обязательств, предусмотренных Контрактом и фактически исполненных Подрядчиком.
9.7.
Штрафы начисляются за неисполнение или ненадлежащее исполнение Подрядчиком
обязательств, предусмотренных Контрактом, за исключением просрочки исполнения
Подрядчиком обязательств (в том числе гарантийного обязательства), предусмотренных
Контрактом.
9.7.1.
Размер штрафа по каждому факту неисполнения или ненадлежащего исполнения
Подрядчиком обязательств, предусмотренных Контрактом, за исключением просрочки
11
исполнения обязательств (в том числе гарантийного обязательства), предусмотренных
Контрактом, устанавливается в соответствии с Постановлением № 1042 в следующем
порядке:
9.7.2.
(а)
10 % цены Контракта в случае, если цена Контракта не превышает 3 млн. рублей.
(б)
5 % цены Контракта в случае, если цена Контракта составляет от 3 млн. рублей до
50 млн. рублей (включительно).
Размер штрафа Подрядчика как победителя закупки (или иного участника закупки в
случаях, установленных Федеральным законом о контрактной системе), предложившего
наиболее высокую цену за право заключения Контракта, по каждому факту неисполнения
или ненадлежащего исполнения Подрядчиком обязательств, предусмотренных
Контрактом, за исключением просрочки исполнения обязательств (в том числе
гарантийного обязательства), предусмотренных Контрактом, устанавливается в
соответствии с Постановлением № 1042 в следующем порядке:
В случае, если цена Контракта не превышает начальную (максимальную) цену Контракта:
(а)
10 % начальной (максимальной) цены Контракта в случае, если цена Контракта не
превышает 3 млн. рублей.
(б)
5 % начальной (максимальной) цены Контракта в случае, если цена Контракта
составляет от 3 млн. рублей до 50 млн. рублей (включительно);
(в)
1 % начальной (максимальной) цены Контракта в случае, если цена Контракта
составляет от 50 млн. рублей до 100 млн. рублей (включительно).
В случае, если цена Контракта превышает начальную (максимальную) цену Контракта:
9.7.3.
(а)
10 % цены Контракта в случае, если цена Контракта не превышает 3 млн. рублей;
(б)
5 % цены Контракта в случае, если цена Контракта составляет от 3 млн. рублей до
50 млн. рублей (включительно);
(в)
1 % цены Контракта в случае, если цена Контракта составляет от 50 млн. рублей до
100 млн. рублей (включительно).
Размер штрафа по каждому факту неисполнения или ненадлежащего исполнения
Подрядчиком обязательства, предусмотренного Контрактом, которое не имеет
стоимостного выражения (при наличии в Контракте таких обязательств), устанавливается
в соответствии с Постановлением № 1042 в следующем порядке:
(а)
1 000 рублей, если цена Контракта не превышает 3 млн. рублей.
(б)
5000 рублей, если цена Контракта составляет от 3 млн. рублей до 50 млн. рублей
(включительно).
9.7.4.
За неисполнение условия о привлечении к исполнению Контракта субподрядчиков из
числа
субъектов
малого
предпринимательства,
социально
ориентированных
некоммерческих организаций Подрядчик несет гражданско-правовую ответственность в
виде штрафа, размер которого составляет 5 (Пять) процентов объема такого привлечения,
установленного Контрактом.
9.8.
Подрядчик несет перед Заказчиком ответственность за последствия неисполнения или
ненадлежащего исполнения обязательств субподрядчиком в соответствии с правилами
пункта 1 статьи 313 и статьи 403 Гражданского кодекса Российской Федерации.
9.9.
В случае обмена документами при применении мер ответственности и совершении иных
действий в связи с нарушением Подрядчиком или Заказчиком условий Контракта в
отношении Контракта, такой обмен осуществляется с использованием ЕИС путем
направления электронных уведомлений. Такие уведомления формируются с
использованием ЕИС, подписываются усиленной электронной подписью лица, имеющего
право действовать от имени Заказчика или Подрядчика, и размещаются в ЕИС без
размещения на официальном сайте.
12
9.10.
В случае, если объем претензионной переписки превысит объемы, допустимые
функционалом ЕИС, дальнейший обмен документами осуществляется в письменной форме
нарочно, почтой заказным письмом либо посредством факсимильной связи или
электронной почты с последующим направлением оригинала по адресам, указанным в
Контракте.
10.
Форс-мажорные обстоятельства
10.1.
Стороны освобождаются от ответственности за частичное или полное невыполнение
обязательств по Контракту, если оно явилось следствием обстоятельств непреодолимой
силы (форс-мажор), а именно: пожара, наводнения, землетрясения, войны, военных
действий, блокады, эмбарго, общих забастовок, и, если эти обстоятельства
непосредственно повлияли на исполнение Контракта.
10.2.
Сторона, для которой создалась невозможность выполнения обязательств по Контракту,
обязана немедленно (в течение 3 (Трех) дней) известить другую Сторону о наступлении и
прекращении вышеуказанных обстоятельств. Несвоевременное извещение об этих
обстоятельствах лишает соответствующую Сторону права ссылаться на них в будущем.
10.3.
Обязанность доказать наличие обстоятельств непреодолимой силы лежит на Стороне
Контракта, не выполнившей свои обязательства по Контракту.
10.4.
Если обстоятельства и их последствия будут длиться более 1 (Одного) месяца, то Стороны
вправе расторгнуть Контракт. В этом случае ни одна из Сторон не имеет права
потребовать от другой Стороны возмещения убытков.
11.
Порядок разрешения споров
11.1.
Все разногласия и споры, которые могут возникнуть при исполнении настоящего
Контракта, подлежат предварительному разрешению путем переговоров, в том числе в
претензионном порядке.
11.2.
Обмен претензиями осуществляется с использованием ЕИС путем направления
электронных уведомлений. Такие уведомления формируются с использованием ЕИС,
подписываются усиленной электронной подписью лица, имеющего право действовать от
имени Заказчика или Подрядчика, и размещаются в ЕИС без размещения на официальном
сайте.
11.3.
При неурегулировании Сторонами спора в досудебном порядке спор разрешается в
Арбитражном суде Санкт-Петербурга и Ленинградской области.
12.
Антикоррупционная оговорка
12.1.
При исполнении своих обязательств по настоящему контракту Стороны, их
аффилированные лица, работники или посредники не выплачивают, не предлагают
выплатить и не разрешают выплату каких-либо денежных средств или ценностей прямо
или косвенно любым лицам для оказания влияния на действия или решения этих лиц с
целью получить какие-либо неправомерные преимущества или иные неправомерные цели.
12.2.
При исполнении своих обязательств по настоящему контракту Стороны, их
аффилированные лица, работники или посредники не осуществляют действия,
квалифицируемые применимым для целей настоящего контракта законодательством как
дача или получение взятки, коммерческий подкуп, а также действия, нарушающие
требования применимого законодательства и международных актов о противодействии
легализации (отмыванию) доходов, полученных преступным путем.
12.3.
В случае возникновения у Стороны обоснованных подозрений, что произошло или может
произойти нарушение каких-либо положений настоящего раздела, соответствующая
Сторона обязуется уведомить другую Сторону в письменной форме. После письменного
уведомления соответствующая Сторона обязана направить подтверждение, что нарушения
13
не произошли или не произойдут. Это подтверждение должно быть направлено в течение
10 (десяти) рабочих дней с даты направления письменного уведомления.
12.4.
В письменном уведомлении Сторона обязана сослаться на обоснованные факты или
предоставить материалы, достоверно подтверждающие или дающие основание
предполагать, что произошло или может произойти нарушение каких-либо положений
настоящего раздела контрагентом, его аффилированными лицами, работниками или
посредниками,
выражающееся
в
действиях,
квалифицируемых
применимым
законодательством как дача или получение взятки, коммерческий подкуп, а также
действиях, нарушающих требования применимого законодательства и международных
актов о противодействии легализации (отмыванию) доходов, полученных преступным
путем.
12.5.
В случае нарушения одной Стороной обязательств воздерживаться от запрещенных в
разделах настоящего контракта действий и (или) неполучения другой Стороной в
установленный настоящим контрактом срок подтверждения, что нарушения не произошли
или не произойдут, другая Сторона имеет право направить обоснованные факты или
предоставить материалы в компетентные органы в соответствии с применимым
законодательством.
13.
Расторжение Контракта
13.1.
Расторжение Контракта допускается по соглашению Сторон, по решению суда, а также в
случае одностороннего отказа Стороны Контракта от исполнения Контракта в
соответствии с гражданским законодательством.
13.2.
Соглашение о расторжении Контракта, заключенного по результатам электронных
процедур, закрытых электронных процедур, заключается с использованием ЕИС. В
случаях, предусмотренных частью 5 статьи 103 Федерального закона о контрактной
системе, такое соглашение не размещается на официальном сайте.
13.3.
Заказчик вправе принять решение об одностороннем отказе от исполнения Контракта по
основаниям, предусмотренным Гражданским кодексом Российской Федерации для
одностороннего отказа от исполнения отдельных видов обязательств.
До принятия такого решения Заказчик вправе провести экспертизу выполненных работ с
привлечением экспертов, экспертных организаций.
13.4.
Если Заказчиком проведена экспертиза выполненных работ с привлечением экспертов,
экспертных организаций, решение об одностороннем отказе от исполнения Контракта
может быть принято Заказчиком только при условии, что по результатам экспертизы
выполненных работ в заключении эксперта, экспертной организации будут подтверждены
нарушения условий Контракта, послужившие основанием для одностороннего отказа
Заказчика от исполнения Контракта.
13.5.
В случае принятия Заказчиком решения об одностороннем отказе от исполнения
Контракта:
1) Заказчик с использованием ЕИС формирует решение об одностороннем отказе от
исполнения Контракта, подписывает его усиленной электронной подписью лица,
имеющего право действовать от имени Заказчика, и размещает такое решение в ЕИС;
2) решение об одностороннем отказе от исполнения Контракта не позднее одного часа с
момента его размещения в ЕИС автоматически с использованием ЕИС направляется
Подрядчику. Датой поступления Подрядчику решения об одностороннем отказе от
исполнения Контракта считается дата размещения в соответствии с настоящим пунктом
такого решения в ЕИС в соответствии с часовой зоной, в которой расположен Подрядчик;
3) поступление решения об одностороннем отказе от исполнения Контракта в
соответствии с подпунктом 2 настоящего пункта считается надлежащим уведомлением
Подрядчика об одностороннем отказе от исполнения Контракта.
14
13.6.
Решение Заказчика об одностороннем отказе от исполнения Контракта вступает в силу и
Контракт считается расторгнутым через 10 (Десять) дней с даты надлежащего
уведомления Заказчиком Подрядчика об одностороннем отказе от исполнения Контракта.
13.7.
Заказчик обязан отменить не вступившее в силу решение об одностороннем отказе от
исполнения Контракта, если в течение десятидневного срока с даты надлежащего
уведомления Подрядчика о принятом решении об одностороннем отказе от исполнения
Контракта устранено нарушение условий Контракта, послужившее основанием для
принятия указанного решения, а также Заказчику компенсированы затраты на проведение
экспертизы выполненных работ с привлечением экспертов, экспертных организаций.
Данное правило не применяется в случае повторного нарушения Подрядчиком условий
Контракта, которые в соответствии с гражданским законодательством являются
основанием для одностороннего отказа Заказчика от исполнения Контракта.
13.8.
В случае отмены Заказчиком в соответствии с Федеральным законом о контрактной
системе не вступившего в силу решения об одностороннем отказе от исполнения
Контракта, Заказчик не позднее одного дня, следующего за днем такой отмены, формирует
с использованием ЕИС извещение об отмене решения об одностороннем отказе от
исполнения Контракта, подписывает его усиленной электронной подписью лица,
имеющего право действовать от имени Заказчика, и размещает такое извещение в ЕИС.
13.9.
Подрядчик вправе принять решение об одностороннем отказе от исполнения Контракта по
основаниям, предусмотренным Гражданским кодексом Российской Федерации для
одностороннего отказа от исполнения отдельных видов обязательств.
13.10. В случае принятия Подрядчиком решения об одностороннем отказе от исполнения
Контракта такое решение направляется Заказчику в следующем порядке:
1) Подрядчик с использованием ЕИС формирует решение об одностороннем отказе от
исполнения Контракта, подписывает его усиленной электронной подписью лица,
имеющего право действовать от имени Подрядчика, и размещает такое решение в ЕИС;
2) решение об одностороннем отказе от исполнения Контракта не позднее одного часа с
момента его размещения в ЕИС автоматически с использованием ЕИС направляется
Заказчику. Датой поступления Заказчику решения об одностороннем отказе от исполнения
Контракта считается дата размещения в соответствии с настоящим пунктом такого
решения в ЕИС в соответствии с часовой зоной, в которой расположен Заказчик;
3) поступление решения об одностороннем отказе от исполнения Контракта в
соответствии с пунктом 2 настоящей части считается надлежащим уведомлением
Заказчика об одностороннем отказе от исполнения Контракта.
13.11. Решение Подрядчика об одностороннем отказе от исполнения Контракта вступает в силу и
Контракт считается расторгнутым через 10 (Десять) дней с даты надлежащего
уведомления Подрядчиком Заказчика об одностороннем отказе от исполнения Контракта.
13.12. Подрядчик обязан отменить не вступившее в силу решение об одностороннем отказе от
исполнения Контракта, если в течение десятидневного срока с даты надлежащего
уведомления Заказчика о принятом решении об одностороннем отказе от исполнения
Контракта устранены нарушения условий Контракта, послужившие основанием для
принятия указанного решения.
13.13. В случае отмены Подрядчиком в соответствии с Федеральным законом о контрактной
системе не вступившего в силу решения об одностороннем отказе от исполнения
Контракта, размещенного в ЕИС, Подрядчик не позднее одного дня, следующего за днем
такой отмены, формирует с использованием ЕИС извещение об отмене решения об
одностороннем отказе от исполнения Контракта, подписывает его усиленной электронной
подписью лица, имеющего право действовать от имени Подрядчика, и размещает такое
извещение в ЕИС.
13.14. Заказчик обязан принять решение об одностороннем отказе от исполнения Контракта в
случае, если в ходе исполнения Контракта установлено, что:
15
(а)
Подрядчик и (или) поставляемый товар перестали соответствовать установленным
извещением об осуществлении закупки и (или) документацией о закупке (если
Федеральным законом о контрактной системе предусмотрена документация о
закупке) требованиям к участникам закупки (за исключением требования,
предусмотренного частью 1.1 (при наличии такого требования) статьи 31
Федерального закона о контрактной системе) и (или) поставляемому товару;
(б)
при определении Подрядчика Подрядчик представил недостоверную информацию
о своем соответствии и (или) соответствии поставляемого товара требованиям,
указанным в подпункте (а) настоящего пункта, что позволило ему стать
победителем определения подрядчика;
(в)
если вследствие реорганизации юридического лица, являющегося Подрядчиком,
его права и обязанности по такому контракту перешли к вновь возникшему
юридическому лицу, зарегистрированному на территории иностранного
государства, в отношении которого в соответствии с подпунктами «а» и «б» пункта
1 части 2 статьи 14 Федерального закона о контрактной системе установлены
запрет закупок работ, соответственно выполняемых иностранными лицами, либо
ограничение закупок работ, соответственно выполняемых иностранными лицами, и
Подрядчик являлся российским лицом, либо в соответствии с подпунктом «в»
пункта 1 части 2 статьи 14 Федерального закона о контрактной системе
установлено преимущество в отношении работ, соответственно выполняемых
российскими лицами, и Подрядчик являлся российским лицом.
13.15. При расторжении Контракта в связи с односторонним отказом Стороны Контракта от
исполнения Контракта другая Сторона Контракта вправе потребовать возмещения только
фактически понесенного ущерба, непосредственно обусловленного обстоятельствами,
являющимися основанием для принятия решения об одностороннем отказе от исполнения
Контракта.
14.
Срок действия и порядок изменения Контракта
14.1.
Контракт вступает в силу с даты его заключения и действует до полного исполнения
Сторонами своих обязательств по Контракту.
Контракт считается заключенным в день размещения Контракта, подписанного усиленной
электронной подписью лица, имеющего право действовать от имени Заказчика, в единой
информационной системе.
14.2.
Изменение существенных условий Контракта при его исполнении не допускается, за
исключением их изменения по соглашению сторон, в частности, в следующих случаях:
14.2.1. при снижении цены Контракта без изменения предусмотренных Контрактом объема
работы, качества выполняемой работы и иных условий Контракта.
14.2.2. если по предложению Заказчика увеличивается предусмотренный Контрактом объем
работы не более чем на десять процентов или уменьшается предусмотренный Контрактом
объем выполняемой работы не более чем на десять процентов. При этом по соглашению
Сторон допускается изменение с учетом положений бюджетного законодательства
Российской Федерации цены Контракта пропорционально дополнительному объему
работы, исходя из установленной в Контракте цены единицы работы, но не более чем на
десять процентов цены Контракта. При уменьшении предусмотренного Контрактом
объема работы Стороны Контракта обязаны уменьшить цену Контракта исходя из цены
единицы работы.
14.3.
Соглашение об изменении условий Контракта, заключенного по результатам электронных
процедур, закрытых электронных процедур, заключается с использованием ЕИС. В
случаях, предусмотренных частью 5 статьи 103 Федерального закона о контрактной
системе, такое соглашение не размещается на официальном сайте.
15.
Прочие условия
16
15.1.
Контракт составлен и подписан в электронном виде. Все приложения к Контракту
являются его неотъемлемой частью. К Контракту прилагаются:
Приложение № 1 «Описание объекта закупки»
Приложение № 2 «Спецификация»
15.2.
В случае изменения наименования, адреса места нахождения или банковских реквизитов
Стороны, она письменно извещает об этом другую Сторону в течение 3 (Трёх) рабочих
дней с даты такого изменения.
15.3.
При исполнении Контракта не допускается перемена Подрядчика, за исключением
случаев, если новый Подрядчик является правопреемником Подрядчика по Контракту
вследствие реорганизации юридического лица в форме преобразования, слияния или
присоединения.
15.4.
В случае перемены Заказчика по Контракту права и обязанности Заказчика по Контракту
переходят к новому Заказчику в том же объеме и на тех же условиях.
16.
Адреса места нахождения, банковские реквизиты и подписи Сторон
Заказчик:
Подрядчик:
ГКУ ЛО "ЦЭПЭ ЛО"
Адрес места нахождения: 191015, 78,
ПЕР., КАЛУЖСКИЙ, Д. 3, ЛИТЕРА А
Почтовый адрес: 191015, 78, ПЕР.,
КАЛУЖСКИЙ, Д. 3, ЛИТЕРА А
ИНН/КПП 7841428446/784201001
ОГРН 1107847200152
ОКТМО 40911000
Тел./факс: 8 812 332 84 88; 8 812 332 84
89/7-812-3328489
E-mail: info@lenoblces.ru
Лицевой счет в финансовом органе:
02367978002
в
КОМИТЕТЕ
ФИНАНСОВ
ЛЕНИНГРАДСКОЙ ОБЛАСТИ
Номер счета
02452000150
финансового
органа:
Лицевой счет в органах Федерального
казначейства: 02367978002
Наименование
ТОФК:
Ленинградской области
УФК
по
БИК ТОФК:
Наименование УФК: УПРАВЛЕНИЕ
ФЕДЕРАЛЬНОГО
КАЗНАЧЕЙСТВА
ПО ЛЕНИНГРАДСКОЙ ОБЛАСТИ
Номер
счета
03221643410000004500
УФК:
Лицевой счет в финансовом органе:
17
06367978005
в
КОМИТЕТЕ
ФИНАНСОВ
ЛЕНИНГРАДСКОЙ ОБЛАСТИ
Номер счета финансового
03222643410000004500
Ответственное
Контракта
лицо
за
органа:
исполнение
Березина Виктория Вячеславовна,
Контрактный управляющий
Тел.: 8 (812) 332-84-88 (118)
От имени Заказчика
От имени Подрядчика
_________________________
_________________________
«___»________________20__г.
«___»________________20__г.
18
Приложение № 1
к Контракту
от «____»__________ _____ г.
№ ______
ОПИСАНИЕ ОБЪЕКТА ЗАКУПКИ
Прилагается отдельным файлом
Заказчик
Подрядчик
_________________________
_________________________
«___»________________20__г.
«___»________________20__г.
19
Приложение № 2
к Контракту
от «____»__________ _____ г.
№ ______
СПЕЦИФИКАЦИЯ
№
Наименование услуг
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Выполнение работ по развитию
региональной государственной
информационной системы
жилищно-коммунального
хозяйства Ленинградской области в
части развития Подсистемы «Учет
потребления коммунальных
ресурсов Ленинградской области»,
в том числе:
Разработка функциональной
возможности выбора периода графика
и реестра в функциональном модуле
«Контроль превышения фактического
теплопотребления от проектного»
раздела «Энергоэффективность»
Разработка функциональной
возможности выбора периода в
модуле «Контроль температурного
графика» раздела
«Энергоэффективность»
Разработка функции «печатная
форма» по разделу «Контроль
температурного графика» из дерева
объектов по выбранному ресурсу
«Теплоснабжение» выбранного
объекта в разделе
Доработка модуля «Реестры» в
разделе формирования отчетности
«Сверхнормативное потребление
тепловой энергии», в части доработки
выбора района при формировании
отчета
Разработка экранной формы
«Контроль температурного графика»
по коммунальной услуге на уровне
объекта потребления
Добавление механизмов расчета
рекомендуемого расхода для
температурных графиков на уровне
объекта потребления, прибор объекта
Разработка интерактивного виджета
на стартовой странице с
функциональной информацией по
перерасходу тепловой энергии от
нормативного показателя в денежном
Объем,
Ед.
измерения
Колво
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
Усл. ед.
1
20
Цена за
ед. услуги без
НДС,
руб.
Цена за
ед.
услуги с
НДС,
руб.
Стоимос
ть услуг
без НДС,
руб.
Стоимос
ть услуг
с НДС,
руб.
1.8
1.9
выражении
Доработка формирования отчета в
модуле «Реестры», раздел
«Превышение лимитов потребления»
в части выбора района без привязки к
подключенным объектам
Миграция (перенос) данных и
объектов схемы данных из текущей
СУБД PostgreSQL в целевую СУБД
Postgres Pro
Усл. ед.
1
Усл. ед.
1
Заказчик
Подрядчик
_________________________
_________________________
«___»________________20__г.
«___»________________20__г.
21

=== ФАЙЛ: Ответ на запрос № 16969 | docs/0145200000426001424/Ответ на запрос № 16969.pdf
Ответ на запрос № 16969
На поступивший запрос о даче разъяснений положений
осуществлении закупки направляем следующий ответ Заказчика.
извещения
об
Запрос:
Извещение № 0145200000426001424. Объект закупки: выполнение работ по развитию
региональной государственной информационной системы жилищно-коммунального хозяйства
Ленинградской области в части развития Подсистемы «Учет потребления коммунальных
ресурсов Ленинградской области».
В соответствии с частью 5 статьи 42 Федерального закона от 05.04.2013 № 44-ФЗ «О
контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных
и муниципальных нужд» просим разъяснить следующие положения извещения об
осуществлении закупки, Описания объекта закупки (далее — ООЗ) и проекта контракта.
1. Сроки этапов испытаний
Таблица 9.1 ООЗ устанавливает календарные даты: подготовка к испытаниям — до
06.11.2026, предварительные испытания — 06.11–20.11.2026, опытная эксплуатация —
23.11–02.12.2026. Согласно п. 4.1 проекта контракта Подрядчик приступает к выполнению
работ с момента заключения Контракта, дата которого определится по итогам процедуры.
1.1. Правильно ли мы понимаем, что даты этапов 1–3 таблицы 9.1 ООЗ уточняются в
частном техническом задании с учетом даты заключения Контракта?
1.2. Правильно ли мы понимаем, что несоблюдение дат этапов 1–3 таблицы 9.1 ООЗ при
соблюдении срока окончания работ, установленного п. 4.2 проекта контракта, не
является нарушением обязательств Подрядчика?
2. Срок представления отчета по уязвимостям
Пункт 9.5.6.3 ООЗ требует представить Отчет по результатам устранения уязвимостей
не позднее чем за 14 календарных дней до направления уведомления о готовности к
предварительным испытаниям, при этом сканирование проводит Заказчик (п. 9.5.6.2), срок
сканирования не установлен.
2.1. В какой срок с даты передачи Подрядчиком исходного кода Заказчик проводит
сканирование и направляет перечень выявленных уязвимостей?
2.2. Правильно ли мы понимаем, что срок, указанный в п. 9.5.6.3 ООЗ, продлевается на
период просрочки Заказчиком направления перечня уязвимостей?
3. Исходный код и документация действующей Подсистемы
ООЗ не устанавливает обязанность и срок передачи Исполнителю исходного кода,
документации и сведений о текущей версии Подсистемы, без которых доработка
невозможна.
Ответ на запрос № 16969
3.1. В какой срок с даты заключения Контракта Заказчик передает Исполнителю
исходные коды всех компонентов Подсистемы, инструкции по сборке и действующую
эксплуатационную и техническую документацию?
3.2. Просим указать перечень имеющейся у Заказчика документации на Подсистему
(наименования документов и даты их последней актуализации).
4. Права на исходный код Подсистемы
На структурной схеме Подсистемы (рисунок 3.1 ООЗ) отражено взаимодействие с сервисом
telemetry.aisgorod.ru, компоненты обозначены как «Web-Сервер ПУ» и «Web-Сервер ЖКХ ID».
4.1. Правильно ли мы понимаем, что исключительные права на программный код всех
компонентов Подсистемы, подлежащих доработке, принадлежат Ленинградской
области, и их доработка третьим лицом не требует согласия иных правообладателей?
4.2. Если нет — просим указать компоненты, права на которые принадлежат третьим
лицам, и условия их доработки.
5. Технологический стек
Таблица 3.1 ООЗ указывает .NET 8, jQuery 3.6.0 и PostgreSQL 14; на рисунке 3.1 отражены
протоколы RDP и MSDeploy.
Просим указать полный перечень языков программирования, фреймворков, библиотек
и их версий, фактически используемых в исходном коде каждого компонента
Подсистемы (Web-Сервер ПУ, Сервер опроса, Служба обработки показаний, Адресный
сервис, Web-Сервер ЖКХ ID), а также операционные системы серверов, на которых они
функционируют.
6. Лицензии Postgres Pro
Пункт 8.9 и пункт 9 таблицы 8.1 ООЗ предусматривают перенос данных в СУБД Postgres
Pro; спецификация не содержит позиции на поставку лицензий.
6.1. Правильно ли мы понимаем, что лицензии СУБД Postgres Pro для всех сред
Подсистемы обеспечивает Заказчик и их приобретение не входит в цену Контракта?
6.2. Просим указать редакцию и версию СУБД Postgres Pro, на которую осуществляется
перенос.
7. Объем логики в базе данных
Пункт 9 таблицы 8.1 ООЗ предусматривает перенос хранимых процедур, функций и
триггеров.
7.1. Просим указать объем базы данных Подсистемы в гигабайтах.
7.2. Просим указать количество хранимых процедур, функций и триггеров, подлежащих
переносу.
Ответ на запрос № 16969
8. Среда разработки и тестирования
Таблица 9.1 ООЗ предусматривает «Развертывание доработанной версии ПО на боевой
системе» и одновременно содержит мероприятие «Проверка корректности установки и
настройки ПО на тестовом контуре».
В какой срок с даты заключения Контракта Заказчик предоставляет Исполнителю
доступ к тестовому контуру Подсистемы, отдельному от среды эксплуатации?
9. Тестовые среды интеграций
Пункт 5.1.2 ООЗ предусматривает предоставление Заказчиком тестовых площадок и
учетных данных смежных систем; таблица 9.1 предусматривает проверку взаимодействия с
РГИС «Энергоэффективность ЛО», ФГИС «Аршин» и другими системами.
В какой срок с даты заключения Контракта Заказчик предоставляет тестовые площадки
и учетные данные РГИС «Энергоэффективность ЛО», подсистемы «ТЭК ЛО» и РГИС
ЖКХ ЛО?
10. Аттестат объекта информатизации Исполнителя
Пункт 9.5.1 ООЗ устанавливает, что доступ Исполнителя к ГИС ЛО осуществляется при
наличии
аттестатов
соответствия
объектов
информатизации
требованиям
информационной безопасности не ниже требований, предъявляемым к ГИС ЛО. Пункт 9.5.3
предусматривает удаленный доступ через ЕСПД ЛО с использованием ViPNet.
10.1. Правильно ли мы понимаем, что для удаленного доступа Исполнителя в порядке п.
9.5.3 ООЗ достаточно подключения к ЕСПД ЛО с использованием ViPNet и аттестат
объекта информатизации Исполнителя не требуется?
10.2. Если аттестат требуется — просим указать класс защищенности ГИС, которому
должен соответствовать объект информатизации Исполнителя.
11. Состав обрабатываемой информации
Приложение № 5 к ООЗ относит все перечисленные сведения к публичной информации, тогда
как п. 9.5.5 ООЗ указывает на обработку персональных данных.
11.1. Просим указать категории информации ограниченного доступа, обрабатываемой в
Подсистеме.
11.2. Если в Подсистеме обрабатываются персональные данные — просим указать
установленный уровень их защищенности.
12. Согласование модели угроз
Пункт 9.5.5 ООЗ предусматривает, что Комитет цифрового развития Ленинградской
области по результатам рассмотрения Заключения принимает решение о направлении
модели угроз на согласование в Уполномоченные органы, а Исполнитель устраняет
полученные от них замечания; срок такого согласования от Исполнителя не зависит.
Ответ на запрос № 16969
Правильно ли мы понимаем, что надлежащим исполнением обязательства является
представление актуализированной модели угроз и Заключения в Комитет цифрового
развития Ленинградской области, а согласование модели угроз Уполномоченными
органами, если Комитет примет решение о ее направлении, не является условием
приемки работ по Контракту?
13. Работа по пункту 5 таблицы 8.1
Пункт 5 таблицы 8.1 ООЗ «Разработка экранной формы «Контроль температурного
графика» по коммунальной услуге на уровне объекта потребления» не имеет детального
описания в разделе 8 ООЗ, в отличие от остальных работ.
Просим указать требования к экранной форме по пункту 5 таблицы 8.1 ООЗ: перечень
отображаемых показателей, правила подбора данных и вид диаграммы.
14. Расчет рекомендуемого расхода
Пункт 8.6.1 ООЗ задает формулу расчета рекомендуемого расхода М2рек через функцию
h(t;P) и текст уведомления «Рекомендуемый расход получился меньше и его надо снизить до
52 т/ч.».
14.1. Просим указать методику (таблицы, стандарт) определения функции h(t;P),
которую должен использовать Исполнитель.
14.2. Правильно ли мы понимаем, что значение «52 т/ч» в тексте уведомления является
примером и подставляется расчетным значением М2рек?
15. Границы приемки
Таблица 9.1 ООЗ предусматривает на этапе приемочных испытаний мероприятие
«Комплексная проверка системы в полном объеме», а разделы 4–6 ООЗ содержат
требования к Подсистеме в целом (отказоустойчивость, автоматическое восстановление,
локальное кэширование и др.).
15.1. Правильно ли мы понимаем, что предметом приемки являются только работы,
перечисленные в таблице 8.1 ООЗ и спецификации?
15.2. Правильно ли мы понимаем, что несоответствие Подсистемы требованиям
разделов 4–6 ООЗ в части, не затронутой доработками, не является основанием для
отказа в приемке?
16. Работы раздела 4.2 и пункта 6.1 ООЗ
Раздел 4.2 ООЗ перечисляет обучение пользователей, разработку стратегического плана
развития Подсистемы, регулярное резервное копирование; п. 6.1 — периодическое
тестирование сценариев отказа. Эти работы не включены в спецификацию.
16.1. Правильно ли мы понимаем, что работы, перечисленные в разделе 4.2 и п. 6.1 ООЗ,
выполняются только в объеме, необходимом для работ таблицы 8.1 ООЗ?
Ответ на запрос № 16969
16.2. Правильно ли мы понимаем, что обучение пользователей ограничивается
консультациями в период опытной эксплуатации?
17. Повторная приемка
Пункт 9.4 ООЗ предусматривает устранение недостатков «в согласованный с Заказчиком
срок» и назначение даты повторной приемки; число повторных приемок не ограничено.
Правильно ли мы понимаем, что при повторной приемке проверяется только
устранение недостатков, зафиксированных в протоколе предыдущей приемки?
18. Ответственность за правомерность компонентов
Пункт 6.7 ООЗ устанавливает полную ответственность Исполнителя за правомерность
использования всех программных компонентов, применённых в рамках Контракта.
Правильно ли мы понимаем, что эта ответственность распространяется только на
компоненты, включенные в Подсистему Исполнителем при выполнении работ по
Контракту, и не распространяется на программное обеспечение Подсистемы, созданное
или приобретенное до заключения Контракта?
19. Гарантийные обязательства
Пункт 7.2 ООЗ распространяет гарантию на все компоненты Подсистемы, «включая
интеграции с внешними системами, разработанные или доработанные в рамках исполнения
Контракта», и по-разному определяет начало гарантийного срока; п. 3.4.6 проекта
контракта — с даты подписания документа о приемке.
19.1. Правильно ли мы понимаем, что гарантийные обязательства распространяются
только на результаты работ, выполненных Исполнителем по Контракту?
19.2. Правильно ли мы понимаем, что гарантийный срок исчисляется с даты
подписания Заказчиком документа о приемке в ЕИС?
20. Границы устранения уязвимостей
Пункт 9.5.6.4 ООЗ предоставляет Заказчику право на внеплановое сканирование Системы, а
п. 9.5.6.6 определяет результат как подтверждение отсутствия уязвимостей в Системе.
Поддержка платформы .NET 8, указанной в таблице 3.1 ООЗ, прекращается производителем
10.11.2026.
20.1. Правильно ли мы понимаем, что по результатам любого сканирования, в том числе
внепланового, Исполнитель обязан устранять только уязвимости функционала,
разработанного или доработанного по Контракту?
20.2. Правильно ли мы понимаем, что уязвимости платформы .NET 8 и иного
общесистемного программного обеспечения, не изменявшегося Исполнителем, не
подлежат устранению Исполнителем в рамках Контракта?
21. Срок приемки
Ответ на запрос № 16969
Пункт 4.2 проекта контракта устанавливает окончание работ не позднее 14.12.2026,
пункты 6.7 и 6.10 — размещение документа о приемке в течение 2 рабочих дней после
выполнения работ и его рассмотрение приемочной комиссией до 20 рабочих дней, тогда как
таблица 9.1 ООЗ относит размещение документа о приемке в ЕИС к этапу, завершающемуся
14.12.2026.
Правильно ли мы понимаем, что обязательство Подрядчика по сроку считается
исполненным, если документ о приемке размещен в ЕИС в сроки, установленные пп. 4.2
и 6.7 проекта контракта, независимо от даты завершения приемки Заказчиком?
22. Требования доступности
Пункт 7.3 ООЗ устанавливает, что Подсистема должна удовлетворять ГОСТ Р 52872-2019.
Правильно ли мы понимаем, что требование ГОСТ Р 52872-2019 распространяется
только на экранные формы, создаваемые или изменяемые по Контракту?
23. Ссылка на порядок приемки
Пункт 9.4 ООЗ указывает, что приемка осуществляется в соответствии с разделом 7 ООЗ,
который содержит требования к составу работ.
Правильно ли мы понимаем, что порядок приемки определяется разделом 9 ООЗ и
разделом 6 проекта контракта?
Ответ просим разместить в единой информационной системе в сфере закупок в сроки,
установленные частью 5 статьи 42 Федерального закона № 44-ФЗ.
Разъяснения заказчика:
1.1. Даты этапов определены в описании объекта закупки, уточнение дат в рамках
частного технического задания не предусмотрено.
1.2. Сокращение сроков испытаний, предусмотренных описанием объекта закупки не
допускается. Поэтому соблюдение срока, установленного в п. 4.2 при несоблюдении сроков,
установленных ООЗ не представляется возможным.
2.1. В течении 2-х рабочих дней.
2.2. П. 9.5.6.3 ООЗ будет скорректирован.
3.1. Передача исходных кодов на внешнем носителе не предусмотрена. Исходные коды
предоставляются в рамках предоставления доступа согласно п. 9.5 ООЗ.
3.2. Документация в рамках государственных контрактов, которые находятся в общем
доступе (https://zakupki.kontur.ru/0145200000425001548).
Ответ на запрос № 16969
4.1. Исключительные права программного кода всех компонентов принадлежат
Ленинградской области и не требуют согласия иных правообладателей.
4.2. Не требуется.
5. PG SQL. Языки программирования: .net, C#, JavaScript, TypeScript, SQL.
6.1. Приобретение СУБД Postgres Pro не входит в сумму контракта.
6.2. По требованию заказчика. В процессе работ требуется обновлять, т.к. могут быть
исправления критических уязвимостей.
7.1. Данные в контракте не фиксируются по причине постоянных обновлений. Кроме
того, объем данных не влияет на исполнение контракта.
7.2. Считаем нецелесообразным указывать конкретные данные в контракте, т.к.
количество хранимых процедур, функций и триггеров - меняется в ходе оказания услуг по
договору информационно-технического сопровождения.
8. Тестовый контур разворачивает Исполнитель на серверах, предоставленных
Заказчиком. Доступ к серверам осуществляется в течение 3-х рабочих дней после заключения
Контракта.
9. Для интеграции с РГИС ЭЭ Исполнителю требуется самостоятельно согласовать
доступ к площадке с государственным казённым учреждением Ленинградской области
«Оператор „электронного правительства“» доступ до ФГИС Аршин - открыт из сети интернет.
10.1. Аттестат обязателен по требованиям к подключению к ЕСПД ЛО.
10.2. Класс защищенности К3.
11.1. Персональные данные сотрудников, персональные данные пользователей, объемы
потребления гвс, хвс, тепла.
11.2. УЗ-3.
12. Устранение замечаний производится в рамках гарантийных обязательств, в случае
поступления замечаний по истечении срока исполнения Контракта. ООЗ будет
скорректирован в новой редакции.
13. Требования к форме “Контроль температурного графика” в Приказе Министерства
энергетики РФ от 5 марта 2019 г. № 212 "Об утверждении Методических указаний по
разработке схем теплоснабжения".
14.1. Постановление Правительства РФ № 1034, Приказ Минстроя России № 99/пр.
14.2. Да.
15.1. Да.
15.2. При этом не должна быть нарушена работоспособность системы в целом.
Ответ на запрос № 16969
16.1. Да.
16.2. Да.
17. Нет. Повторная приемка работ осуществляется в рамках полного объема доработок.
18. Да.
19.1. Да.
19.2. Да.
20.1. Да.
20.2. Да.
21. Срок 14.12 включает в себя срок проведения испытаний, указанных в ООЗ,
размещение документа подрядчика в ЕИС. Дальнейшие действия заказчика определены в п.
6.9. Контракта.
22. Да.
23. Да. ООЗ будет скорректирован в новой редакции.
