СОГЛАСОВАНО УТВЕРЖДАЮНачальник главного управления МЧС России по Сахалинской области

Заместитель председателя Правительства Сахалинской области

___________________А.А. Андреев __________________В.С. Сидоренко

«___» _____________ 2019 г. «___» _____________ 2019 г.

СОГЛАСОВАНО СОГЛАСОВАНОИсполняющий обязанности министерства цифрового развития и связи Сахалинской области

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

___________________Д.Л. Мажарин __________________А.В. Михеева

«___» _____________ 2019 г. «___» _____________ 2019 г.

Аппаратно-программный комплекс «Безопасный город»на территории Сахалинской области

АПК БГ

ТЕХНИЧЕСКОЕ ЗАДАНИЕНА ВЫПОЛНЕНИЕ РАБОТ ПО РАЗВИТИЮ АППАРАТНО-

ПРОГРАММНОГО КОМПЛЕКСА «БЕЗОПАСНЫЙ ГОРОД» НА ТЕРРИТОРИИ САХАЛИНСКОЙ ОБЛАСТИ

На 98 листах

Южно-Сахалинск 2019

СОГЛАСОВАНОГенеральный конструктор АПК «Безопасный город»

___________________

«___» _____________ 2019 г.

Содержание1 Общие сведения................................................................................................................6

1.1 Полное наименование Системы..............................................................................6

1.2 Условное обозначение Системы..............................................................................6

1.3 Шифр темы................................................................................................................6

1.4 Заказчик.....................................................................................................................6

1.5 Пользователь.............................................................................................................6

1.6 Исполнитель..............................................................................................................6

1.7 Основание для развития Системы...........................................................................6

1.8 Плановые сроки развития Системы........................................................................7

1.9 Источник финансирования.......................................................................................8

1.10 Порядок финансирования.....................................................................................8

1.11 Порядок оформления и предъявления Заказчику результатов работ..............8

1.12 Права на результаты работ...................................................................................8

1.13 Перечень сокращений...........................................................................................8

1.14 Термины и определения, используемые в ТЗ...................................................10

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

2 Назначение и цели развития Системы.........................................................................13

2.1 Назначение Системы..............................................................................................13

2.2 Цели и задачи выполнения работ..........................................................................13

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

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

3.2 Сведения об условиях эксплуатации объекта автоматизации и

характеристиках окружающей среды.........................................................................................16

3.2.1 Условия эксплуатации комплекса технических средств...............................16

3.2.2 Характеристики окружающей среды..............................................................16

3.3 Описание места объекта автоматизации в совокупности окружающих

автоматизированных информационных систем........................................................................16

3.3.1 Сведения о внешней среде...............................................................................16

3.4 Текущее состояние объекта автоматизации.........................................................18

3.5 Общие принципы развития Системы....................................................................28

4 Требования к системе.....................................................................................................29

4.1 Требования к системе в целом...............................................................................29

4.1.1 Требования к структуре и функционированию системы..............................29

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

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

4.1.3 Показатели назначения.....................................................................................37

4.1.4 Требования к надежности.................................................................................38

4.1.5 Требования к безопасности..............................................................................40

4.1.6 Требования к транспортабельности для подвижных АС..............................41

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

хранению компонентов системы.............................................................................................41

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

4.1.9 Требования к защите информации от несанкционированного доступа......42

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

4.1.11 Требования к патентной чистоте...................................................................44

4.1.12 Дополнительные требования.........................................................................45

4.1.13 Требования к электронным учебным курсам...............................................45

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

4.2.1 Требования к функциональному развитию АПК...........................................49

4.2.2 Требования к тиражированию КСА ЕЦОР.....................................................63

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

4.3.1 Требования к математическому обеспечению...............................................67

4.3.2 Требования к информационному обеспечению.............................................67

4.3.3 Требования к лингвистическому обеспечению..............................................69

4.3.4 Требования к программному обеспечению....................................................70

4.3.5 Требования к техническому обеспечению.....................................................70

4.3.6 Требования к метрологическому обеспечению.............................................71

4.3.7 Требования к телекоммуникационному обеспечению системы..................71

4.3.8 Требования к другим видам обеспечения.......................................................71

5 Состав и содержание работ по развитию системы.....................................................72

5.1 Этапы работ.............................................................................................................72

5.2 Дополнительные сведения.....................................................................................75

6 Порядок контроля и приемки системы........................................................................76

6.1 Виды, состав, объем и методы испытаний системы и ее составных частей.....76

6.2 Общие требования к приемке работ по стадиям..................................................76

6.3 Сведения о гарантийном обслуживании системы...............................................77

6.4 Порядок выполнения доработок и устранения допущенных Исполнителем

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

77

6.5 Статус приемочной комиссии................................................................................78

6.6 Сведения об обслуживании системы....................................................................78

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

вводу системы в действие................................................................................................................79

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

7.2 Приведение поступающей в систему информации к виду, пригодному для

обработки с помощью ЭВМ........................................................................................................79

7.3 Изменения, которые необходимо осуществить в объекте автоматизации........79

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

служб 80

7.5 Сроки и порядок комплектования штатов и обучения персонала.....................80

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

9 Источники разработки...................................................................................................83

9.1 Нормативно-правовые акты...................................................................................83

9.2 Нормативно-технические документы...................................................................85

Приложение А. Форма отчета «Ежедневная оперативная информация по

температурному режиму в МО в период прохождения отопительного сезона»........................87

Приложение Б. Перечень периодических отчетов ЦУКС..............................................89

Приложение В. Строевая записка.....................................................................................99

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

1.1 Полное наименование СистемыАппаратно-программный комплекс «Безопасный город» на территории Сахалинской

области (далее – Система).

1.2 Условное обозначение СистемыАПК БГ

1.3 Шифр темыАПКБГ.2019

1.4 ЗаказчикГосударственное бюджетное учреждение Сахалинской области «Сахалинский

областной центр информатизации» - ГБУ СО «СОЦИ» (далее – Заказчик).Юридический адрес: 693000, Сахалинская область, город Южно-Сахалинск,

Коммунистический проспект, 39 В;Адрес для переписки: 693000, Сахалинская область, город Южно-Сахалинск,

Коммунистический проспект, 39 В.

1.5 ПользовательПользователями Системы являются:

сотрудники Единых центров оперативного реагирования; граждане, осуществляющие взаимодействие с «Открытым порталом»; сотрудники служб ДДС; сотрудники ЦУКС; сотрудники ФСБ.

1.6 ИсполнительИсполнитель определяется по результатам проведения конкурсной процедуры в

соответствии с федеральным законом 5 апреля 2013 года N 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

1.7 Основание для развития СистемыОснованием для модернизации являются следующие документы:

Федеральный закон от 21.12.1994 № 68-ФЗ (ред. от 23.06.2016) «О защите населения и территорий от чрезвычайных ситуаций природного и техногенного характера»;

Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»;

Федеральный закон от 27.07.2006 года № 152-ФЗ «О персональных данных»;

Постановление Правительства РФ от 01.11.2012 N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;

Постановление Правительства РФ от 08.09.2010 № 697 (ред. от 11.08.2016) «О единой системе межведомственного электронного взаимодействия»;

Постановление Правительства РФ от 25.08.2008 № 641 (ред. от 17.12.2010) «Об оснащении транспортных, технических средств и систем аппаратурой спутниковой навигации ГЛОНАСС или ГЛОНАСС/GPS»;

Указ Президента Российской Федерации от 28.12.2010 № 1632 «О совершенствовании системы обеспечения вызова экстренных оперативных служб на территории Российской Федерации»;

Распоряжение Правительства Российской Федерации от 03.12.2014 №2446-р об утверждении Концепции построения и развития аппаратно-программного комплекса «Безопасный город»;

Постановление Правительства РФ от 21.11.2011 N 958 (ред. от 06.03.2015) "О системе обеспечения вызова экстренных оперативных служб по единому номеру "112";

Постановление Правительства РФ от 16.03.2013 № 223 (ред. от 23.03.2016) «О федеральной целевой программе «Создание системы обеспечения вызова экстренных оперативных служб по единому номеру "112" в Российской Федерации на 2013 - 2017 годы»;

Постановление Правительства Российской Федерации от 30.12.2003 №794 (ред. от 14.04.2015) «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»;

Постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» (вместе с "Правилами формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных", "Порядком подготовки обоснования невозможности соблюдения запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд");

Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;

Указ Президента Российской Федерации от 13.11.2012 № 1522 «О создании комплексной системы экстренного оповещения населения об угрозе возникновения или о возникновении чрезвычайных ситуаций»;

другие нормативные правовые, организационно-методические и нормативно-технические документы по вопросам построения и развития АПК «Безопасный город», введенные в действие во исполнение поручения Президента Российской Федерации от 27.05.2014 № Пр-1175;

Положение о единой дежурно-диспетчерской службе муниципального образования (Утверждено протоколом заседания Правительственной комиссии по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности от 28 августа 2015 г. № 7).

1.8 Плановые сроки развития СистемыСрок начала работ: с момента заключения Договора.Сроки начала и окончания этапов работ уточнены в разделе 5 настоящего ТЗ.

1.9 Источник финансированияФинансирование работ осуществляется за счет средств регионального бюджета

Сахалинской области.

1.10 Порядок финансированияПорядок финансирования работ определяется действующими нормативно-

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

1.11 Порядок оформления и предъявления Заказчику результатов работКомплектность документов, порядок оформления и предъявления Заказчику

результатов работ по развитию Системы приведены в разделах 5, 6 и 8 данного ТЗ.Результаты работ передаются Заказчику в порядке, определенном Договором в

соответствии с Календарным планом работ Договора на основании Актов выполненных работ.

Документация должна быть: передана на бумажных носителях (два экземпляра); передана на машинных носителях (CD/DVD).

Текстовые документы, передаваемые на машинных носителях, должны быть представлены в форматах Microsoft Office.

Все материалы передаются с сопроводительными документами Исполнителя.

1.12 Права на результаты работ Исключительные права и права собственности на результаты работ, отчетные

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

Исключительные права и права собственности на результаты выполнения работ, отчетные документы и материалы, полученные в ходе выполнения настоящего Договора, переходят к Государственному заказчику с момента подписания им Акта сдачи-приемки выполненных работ по Договору (этапу Договора).

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

1.13 Перечень сокращенийПеречень сокращений приведен в таблице 1.

Таблица 1 — Перечень сокращений

Сокращение Полное наименование

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

Сокращение Полное наименование

АПК Аппаратно-программный комплекс

АРМ Автоматизированное рабочее место

БД База данных

ГБУЗ Государственное бюджетное учреждение здравоохранения

ГИС Геоинформационная система

ГЛОНАСС Глобальная навигационная спутниковая система

ГОСТ Государственный стандарт

ГУП Государственное унитарное предприятие

ДДС Дежурная диспетчерская служба

ДРСУ Дорожное ремонтно-строительное управление

ЕЦОР Единый центр оперативного реагирования

ЕДДС Единая дежурно-диспетчерская служба

ЕСИА Единая система идентификации и аутентификации

ИС Информационная система

КСА Комплекс средств автоматизации

КСиП Кризисные ситуации и происшествия

КСП Кризисные ситуации и происшествия

МПЛ Массовое пребывание людей

МЧС России Министерство Российской Федерации по делам гражданской обороны, чрезвычайным ситуациям и ликвидации последствий стихийных бедствий

МО Муниципальное образование

МУП Муниципальное унитарное предприятие

НДВ Недекларированные возможности

ОАО Открытое акционерное общество

ОДС Оперативная дежурная смена

ОМПЛ Объект массового пребывания (постоянного и/или временного нахождения) людей

ООО Общество с ограниченной ответственностью

ОС Операционная система

ПАК Программно-аппаратный комплекс

Сокращение Полное наименование

ПВР Пункты временного размещения

ПО Программное обеспечение

РД Руководящий документ

РСЧС Единая государственная система предупреждения и ликвидации чрезвычайных ситуаций

РФ Российская Федерация

Система-112 Система обеспечения вызова экстренных оперативных служб по единому номеру «112»

СПО Специальное программное обеспечение

СУБД Система управления базами данных

ТСД Терминал сбора данных

ТЗ Техническое задание

ТИ Телекоммуникационная инфраструктура

ТС Транспортное средство

ФГУЗ Федеральное государственное учреждение здравоохранения

ФИАС Федеральная информационная адресная система

ФЗ Федеральный закон

ФСТЭК Федеральная служба по техническому и экспортному контролю

ФСБ России Федеральная Служба Безопасности Российской Федерации

ЦРБ Центральная районная больница

ЦУКС Центр управления в кризисных ситуациях

ЧС Чрезвычайная ситуация

ЭВМ Электронная вычислительная машина

1.14 Термины и определения, используемые в ТЗТермины и определения приведены в таблице 2.

Таблица 2 — Термины и определения

Термин Определение

«Горячая» замена Замена без остановки АПК

log-файл Файл, содержащий записи о событиях в системе

Online-режим Режим реального времени

Термин Определение

АПК «Безопасный город» Аппаратно-программный комплекс (набор технических и программных средств, работающих совместно для выполнения одной или нескольких сходных задач) «Безопасный город»

Валидация Набор процедур по доказательству соответствия определенным критериям

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

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

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

Интеграция Организация передачи данных из одной системы в другую

Информационная безопасность

Процесс обеспечения конфиденциальности, целостности и доступности информации

Информационно-коммуникационная платформа

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

Итерационный подход Выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы

Классификатор/ Справочник

Объект системы содержащий условно-постотянную информацию

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

Консультация Обсуждение какого-либо вопроса

Контракт Соглашение двух или более лиц об установлении, изменении или прекращении гражданских прав и обязанностей

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

Непротиворечивое состояние

Соответствие состояния системы её внутренней логике, структуре и всем явно заданным правилам

Термин Определение

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

Нормативная база Совокупность документов, определяющих нормативное регулирование

Обращение Призыв, речь или просьба, обращённые к операторам системы

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

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

Пространственные данные Данные о пространственных объектах и их наборах.

Регламент Правила, регулирующие порядок деятельности

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

Система Комплекс взаимодействующих компонентов

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

Тайл Квадратное растровое изображение равной величины, которые служат фрагментами отображаемой карты

Экомониторинг Мониторинг экологической обстановки

Эксплуатанты/владельцы ПОО

Лицо, осуществляюще эксплуатацию

1.15 Порядок внесения изменений и дополненийИзменения настоящего ТЗ не предусмотрены. Детализация и дополнение требований

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

2 Назначение и цели развития Системы

2.1 Назначение СистемыСистема предназначена для повышения уровня общественной безопасности и

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

Базовым элементом Системы является комплекс средств автоматизации "Единый центр оперативного реагирования" (далее - КСА ЕЦОР) – это объединение программно-аппаратных средств для комплексной информатизации процессов Единой дежурно-диспетчерской службы (ЕДДС). Комплекс повышает уровень безопасности, комфорта проживания и эффективности управления муниципальным образованием.

2.2 Цели и задачи выполнения работОсновными целями развития Системы являются:

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

повышение скорости реагирования на различные КСиП; увеличение автоматизации процессов ЕДДС, уменьшение влияния

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

увеличение функционала Подсистемы приема и обработки сообщений (п.4.2.1.1 настоящего ТЗ);

увеличение функционала Геоинформационной интеграционной подсистемы (п.4.2.1.2 настоящего ТЗ);

увеличение функционала Подсистемы интеграции данных (п.4.2.1.3 настоящего ТЗ);

разработка Подсистемы информационно-аналитического сопровождения (п.4.2.1.4 настоящего ТЗ);

отказ от использования Подсистемы комплексного мониторинга и создание Подсистемы комплексного мониторинга и управления (п.4.2.1.5 настоящего ТЗ);

увеличение функционала Подсистемы обеспечения информационной безопасности (п.4.2.1.6 настоящего ТЗ);

увеличение функционала Подсистема поддержки принятия решений (п.4.2.1.7.1 - п.4.2.1.7.4 настоящего ТЗ) с разработкой нового модуля ведения реестра ресурсов, сил и средств (п.4.2.1.7.5 настоящего ТЗ);

увеличение функционала Подсистемы управления справочниками и классификаторами (п.4.2.1.8 настоящего ТЗ);

увеличение функционала Подсистемы электронного взаимодействия с муниципальными службами и населением (п.4.2.1.9 настоящего ТЗ);

увеличение функционала Подсистемы электронного взаимодействия с должностными лицами (п.4.2.1.10 настоящего ТЗ);

разработка Подсистемы электронного документооборота (п.4.2.1.11 настоящего ТЗ);

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

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

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

выполнение всех требований, указанных в пункте 4 настоящего ТЗ; успешное прохождение испытаний Системы (п.6.1 настоящего ТЗ).

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

3.1 Краткие сведения об объекте автоматизацииОбъектом автоматизации в рамках настоящих работ является деятельность ЕДДС на

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

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

К основным функциям ЕДДС относятся: прием от населения сообщений о КСиП, несущих информацию об

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

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

обработка и анализ данных о КСиП, определение ее масштаба и состава дежурно-диспетчерских служб, привлекаемых для реагирования на КСиП, их оповещение о переводе в высшие режимы функционирования РСЧС;

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

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

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

обобщение информации о произошедших КСиП, ходе работ по их ликвидации и представление соответствующих докладов по подчиненности.

Пользователями Системы являются: сотрудники ФСБ и ЦУКС; сотрудники ЕДДС; сотрудники ДДС; граждане посредством взаимодействия с порталом (правильное название

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

Основные сведения об объекте автоматизации приведены в следующих документах: ГОСТ Р 22.7.01-2016 Безопасность в чрезвычайных ситуациях. Единая

дежурно-диспетчерская служба (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 29 июня 2016 г. N 723-ст);

положение о единой дежурно-диспетчерской службе муниципального образования (Утверждено протоколом заседания Правительственной комиссии по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности от 28 августа 2015 г. № 7).

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

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

соответствовать Гигиеническим требованиям к персональным электронно-вычислительным машинам и организации работы (СанПиН 2.2.2/2.4.1340-03).

3.2.2 Характеристики окружающей средыХарактеристики окружающей среды в местах установки технических средств

должны соответствовать требованиям следующих документов: ГОСТ Р ИСО 14001-98. Системы управления окружающей средой.

Требования и руководство по применению; СанПиН 2.2.24.548-96. Физические факторы производственной среды.

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

СанПиН 2.2.2/2.4.1340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы.

3.3 Описание места объекта автоматизации в совокупности окружающих автоматизированных информационных систем

3.3.1 Сведения о внешней средеИнформационные системы, с которыми Система осуществляет взаимодействие,

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

Система взаимодействует со следующими внешними системами: Система 112 (Cистема обеспечения вызова экстренных оперативных

служб по единому номеру «112» на территории Сахалинской области); АДИС (Система управления вызовами станции скорой помощи

области); Ангел (Информация по прохождению транспортных средств в зоне

контроля камер); ПАК «Колибри» (SCADA система мониторинга и управления насосным

и котельным оборудованием); Сатурн «LanMon4» (Мониторинг общедомовых счетчиков тепло и

водоснабжения); ГеоИС (Геонифонмационная система Сахалинской области); Сейсмомониторинг (мониторинг сейсмической активности);

ПАК «Молния» (мониторинг отравляющих химических веществ); Камеры «Кречет» (камеры дорожной обстановки); Камеры «Автоураган» (камеры дорожной обстановки); AXXON (Видеонаблюдение в г. Южно-Сахалинск в местах массового

пребывания людей, спортивные площадки, дворовые территории); Интеллект (видеонаблюдение в г. Южно-Сахалинск в местах массового

пребывания людей); Интеллект (видеонаблюдение в г. Корсаков в местах массового

пребывания людей); Интеллект (видеонаблюдение в г. Невельск в местах массового

пребывания людей); ПАК «ClearSCADA» (SCADA система мониторинга оборудования на

водозаборах); SKADA Котельная (SCADA система мониторинга котельного

оборудования); SKADA Скважины (SCADA система мониторинга оборудования на

водозаборах. Скважин 8 ед.); SKADA Канализационнонасосные станции (SCADA система

мониторинга очистных сооружений. Канализационно-насосных станций (КНС)-11 ед.);

Wialon (Невельское ДРСУ) АСК Навигация (Система мониторинга транспорта скорой помощи

области); Wialon (ГО и ЧС ЮС); ГЕЛИОС (ГЛОНАСС/GPS мониторинг автотранспорта г. Южно-

Сахалинске); Омником (ГЛОНАСС/GPS мониторинг автотранспорта); Омником (СКК, ГЛОНАСС/GPS мониторинг автотранспорта) Wialon (ГЛОНАСС/GPS мониторинг автотранспорта г. Южно-

Сахалинске); TRBOnet (Навигационные и телеметрические данные от радиостанций); SmartPTT (Навигационные и телеметрические данные); ГЛОНАСС МЧС (ГЛОНАСС/GPS мониторинг автотранспорта

пожарных экипажей Сахалинской области); «Wialon»(КУИ г.Невельск) АПК «Лавина» (мониторинг объектов, оснащенных оборудованием

пожарной сигнализации); NAVIgard WINSAMM ВДПО (мониторинг объектов, оснащенных

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

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

сигнализации); СПО «Кобра» (мониторинг объектов, оснащенных оборудованием

пожарной сигнализации).На этапе Технического проекта Заказчик предоставит документацию на Систему,

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

3.4 Текущее состояние объекта автоматизацииСистема в архитектурном ландшафте (рисунок 1) состоит из подсистем и модулей

представленных в таблице 3.

Таблица 3 — Состав и описание подсистем и модулей Системы№ Подсистема Модули1 Подсистема интеграции данных -

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

Каждая интеграция является отдельным модулем

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

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

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

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

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

моделирование развития КСиП в зависимости от ассоциируемых с территорией рисков;

определяет вовлеченность в происшествие;

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

автоматической корректировки расчетов с учетом семантических связей с характеристиками территории в расчетной зоне поражения;

автоматического расчета зоны оповещения

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

формирование сценариев реагирования для всех привлекаемых реагированию на КСП;

предоставление рекомендаций по привлечению сил и средств для каждой из служб в зависимости от категории КСП,

формирование инструкций диспетчеру ЕДДС по обработке зарегистрированного события на основе утвержденных регламентов при ликвидации КСП и происшествий;

формирование на основании сценариев реагирования совокупного плана реагирования по КСП

Модуль информационно-справочной поддержки - предназначен для выполнения следующих функций:

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

актуальной на дату, выбранную пользователем;

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

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

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

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

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

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

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

контроль и поддержание в готовности к переводу в высшие режимы функционирования муниципальных органов повседневного управления

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

формирование графиков и отчетов по работе ЕДДС и ДДС

на основе имеющейся (накапливаемой) в КСА ЕЦОР информации;

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

подготовка и представление по подчиненности докладов (донесений) об угрозе или возникновении КСиП;

поиск необходимой информации в банке данных;

подготовка и экспорт данных для анализа;

формирование отчетных форм; автоматизированное

формирование оперативной обстановки на основе записей в журнале КСиП за сутки;

интерактивное редактирование списка (отбор) в зависимости от классификации записи;

фильтрация записей по реквизитам;

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

4 Подсистема приема и обработки сообщений – КСА ЕЦОР предназначена для приема и обработки сообщений в категорированном виде и виде голосовых записей о происшествиях на территории муниципального образования, контроля исполнения поручений по связанным с зарегистрированными событиями сценариям реагирования, обеспечение хранения структурированной информации по поступившим сообщениям в базе данных, а также контроля качества работы диспетчеров

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

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

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

формирование регистрационной карточке и соответствующей ей сценариев реагирования

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

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

Каждая интеграция является отдельным модулем

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

 Каждая интеграция является отдельным модулем

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

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

угрозам, которые направлены на объект защиты

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

9 Подсистема администрирования - предназначена для установки, изменения и контроля основных параметров АПК БГ в процессе его эксплуатации.

Каждая интеграция является отдельным модулем

Обеспечивает выполнение следующих функций:

администрирование операционных систем, сетевого и инструментального программного обеспечения, входящего в АПК БГ;

контроль исправности основных элементов Системы;

сбор и хранение данных о параметрах функционирования основных элементов Системы;

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

10 Подсистема управления справочниками и классификаторами - является неотъемлемым компонентом информационно-коммуникационной инфраструктуры АПК «Безопасный город», обеспечивающим управление всей справочной информацией в Системе

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

Рисунок 1 — Архитектурный ландшафт Системы

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

Задачами Системы являются: обеспечение приема и маршрутизации информации между ЕДДС и ДДС

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

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

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

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

своевременная поддержка процессов принятия управленческих решений по экстренному предупреждению и ликвидации КСиП;

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

развитие процессов оперативно-диспетчерского управления муниципального образования на базе ЕДДС, как центрального органа управления Комплекса, и взаимодействующих с ней экстренных оперативных служб, городских дежурно-диспетчерских, оперативно-дежурных, аварийно-спасательных служб и соответствующих дежурных служб организаций - эксплуатантов/владельцев ПОО, ОМПЛ, расположенных или имеющих область ответственности на территории соответствующего муниципального образования;

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

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

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

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

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

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

3.5 Общие принципы развития СистемыВ соответствии с РД 50-680–88 при модернизации Системы необходимо

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

1 Принцип системностиПри декомпозиции должны быть установлены такие связи между структурными

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

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

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

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

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

4 Принцип стандартизации (унификации)Должны быть рационально применены типовые, унифицированные и

стандартизованные элементы, проектные решения, пакеты прикладных программ, комплексы, компоненты.

5 Принцип эффективностиДолжно быть достигнуто рациональное соотношение между затратами на

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

Дополнительно должны соблюдаться:6 Принцип развития (модифицируемости)

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

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

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

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

4 Требования к системе

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

4.1.1 Требования к структуре и функционированию системыВ рамках работ по развитию Системы, Исполнитель должен провести анализ

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

Архитектура Системы должна быть разработана в соответствии с трехуровневой клиент-серверной архитектурой и состоять из следующих уровней (рисунок 2):

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

приложениями.

Рисунок 2 — Типовая схема трехуровневой архитектуры

Архитектура на уровне приложений должна быть реализована как сервис-ориентированная и поддерживать работу по HTTP/HTTPS.

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

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

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

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

пространственных данных об объектах; обеспечение пользовательской настройки аналитических функций с

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

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

Уровень хранения данных должен удовлетворять следующим требованиям:

поддержка управления версиями семантических и пространственных данных об объектах на дату и время;

обеспечение возможности хранения версий пространственных и семантических данных по объектам Системы на момент времени;

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

4.1.1.1 Перечень подсистем, их назначение и основные характеристики

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

Назначение подсистем представлено в п. 3.4, 4.2.1.4, 4.2.1.5, 4.2.1.11 настоящего ТЗ.

Рисунок 3 — Целевая схема подсистем и модулей Системы по итогам развития

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

31

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

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

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

взаимодействие посредством внутренних программных интерфейсов (API) в режиме on-line;

обмен данными посредством веб-сервисов в режиме on-line.Информационное взаимодействие на сетевом уровне должно строиться с

использованием протоколов стека TCP/IP.

4.1.1.3 Требования по взаимосвязям системы с внешними и со смежными системами, обеспечению ее совместимости

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

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

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

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

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

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

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

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

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

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

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

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

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

обновление ПО и данных; резервное копирование.

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

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

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

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

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

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

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

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

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

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

программного обеспечения – среды электронного взаимодействия, операционных систем серверов и рабочих станций, СУБД и СПО.

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

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

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

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

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

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

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

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

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

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

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

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

транзакций и т.п.).

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

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

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

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

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

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

Число пользователей: 1500; Объем хранимой информации: 40 ТБ.

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

4.1.2.1 Требования к численности персонала Системы

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

Обслуживающий персонал Системы включает следующие категории: Администратор Системы; ГИС-специалист.

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

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

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

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

Основными обязанностями Администратора Системы являются: установка, настройка и мониторинг работоспособности системного и

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

Системы.Основными обязанностями ГИС-специалиста:

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

основы); обработка и анализ пространственных данных в Системе; настройка правил объединения пространственных и семантических

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

Администратор Системы – 1 штатная единица; ГИС специалист – 1 штатная единица.

4.1.2.2 Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков

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

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

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

иметь навыки работы с серверным и телекоммуникационным оборудованием;

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

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

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

4.1.2.3 Требуемый режим работы персонала Системы

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

Режим работы персонала должен соответствовать Гигиеническим требованиям к персональным электронно-вычислительным машинам и организации работы (Санитарные правила и нормы. СанПиН 2.2.2/2.4.1340-03).

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

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

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

Модернизированная Система должна позволять работать пользователям, не обладающим специальной профессиональной подготовкой ГИС-специалиста и обладающим знаниями и навыками работы в качестве Пользователя персональных компьютеров в соответствии с Приложением к приказу Мининформсвязи РФ от 27.12.2005 г. № 147 «Об утверждении квалификационных требований к федеральным государственным гражданским служащим и государственным гражданским служащим субъектов Российской Федерации в области использования информационных технологий», в том числе следующими базовыми знаниями:

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

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

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

4.1.2.5 Требуемый режим работы пользователей Системы

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

4.1.3 Показатели назначения

4.1.3.1 Количество пользователей

К показателям количества пользователей относятся: расчетное количество пользователей;

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

таблице 4.

Таблица 4 — Определения показателей, связанных с количеством пользователей в Системе

№ Показатель Определение

1 Расчетное количество пользователей

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

2 Расчетное количество одновременно работающих пользователей

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

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

Таблица 5 — Значения показателей количества пользователей

№ Показатель Значение

1 Расчетное количество пользователей 500

2 Расчетное количество одновременно работающих пользователей 150

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

4.1.3.2 Сохранение карточки

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

4.1.3.3 Изменение карточки

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

4.1.3.4 Открытие списка карточек КСиП

Показатель характеризует время необходимое для открытия списка карточек КСиП. Данный показатель не должен превышать: 6 секунд для 30 карточек, 9 секунд для 50 карточек, 16 секунд для 100 карточек.

4.1.3.5 Открытие карточки КСиП (задачи)

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

4.1.3.6 Запуск задачи

Показатель характеризует запуск задачи. Данный показатель не должен превышать 4 секунды.

4.1.3.7 Завершение задачи

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

4.1.3.8 Поиск карточки КСиП в общей базе

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

4.1.3.9 Пропускная способность

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

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

необходимо обеспечить, представлено в таблице 6.

Таблица 6 — Значения показателей пропускной способности Системы

№ Наименование информационного потока Количество карточек за час

1 Расчетное количество создаваемых карточек за час

20

2 Максимальное расчетное количество карточек 65

4.1.4 Требования к надежности

4.1.4.1 Показатели доступности/надежности

К показателям доступности/надежности относятся: доступность; надежность; время сохранности данных; время восстановления после сбоя.

Пояснения по показателям, связанным с доступностью/надежностью, приведены в таблице таблица 7.

Таблица 7 — Определения показателей, связанных с доступностью/надежностью

№ Показатель Определение

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

2 Доступность, измеряется в процентах

Доступность – способность Система выполнять согласованною функцию в течении оговоренного времени ((время работы Системы – время простоя)/время работы Системы * 100).

3 Время сохранности данных (Recovery Point Objective – RPO),

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

№ Показатель Определение

измеряется в часах утрачены данные

4 Время восстановления после сбоя (Recovery Time Objective – RTO), измеряется в часах

Время восстановления после сбоя – допустимое время восстановления работоспособности

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

Таблица 8 — Значения показателей доступности/надежности

№ Показатель Значение

1 Надежность, измеряется в часах 5000 часов

2 Доступность, измеряется в процентах 99,5 %

3 Время сохранности данных (Recovery Point Objective – RPO), измеряется в часах

12 часов

4 Время восстановления после сбоя (Recovery Time Objective – RTO), измеряется в часах

4 часа

4.1.4.2 Требования к программным мероприятиям по обеспечению надежности

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

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

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

возможностью их «горячей» замены; использование программного резервирования (программной

избыточности); конфигурирование используемых средств и применение

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

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

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

персонала; регламентации и нормативного обеспечения выполнения работ

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

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

компонентов КТС.

4.1.5 Требования к безопасностиКонструкция комплекса технических средств Системы должна обеспечивать

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

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

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

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

Все внешние элементы технических средств, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь защитное заземление в соответствии с ГОСТ 12.1.030-81 «Электробезопасность. Защитное заземление. Зануление».

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

Аппаратное обеспечение Системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».

Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании Системы в процессе эксплуатации.

Аппаратная часть Системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».

Значения эквивалентного уровня акустического шума, создаваемого аппаратурой Системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:

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

60 дБ - при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

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

Выполнение требований к безопасности обеспечиваются Заказчиком.

4.1.6 Требования к эргономике и технической эстетикеВ качестве нормативно-технической документации при эргономическом

проектировании компонентов интерфейса Системы должны использоваться государственные стандарты (в том числе стандарты серии ССЭТО — системы стандартов эргономических требований и эргономического обеспечения) и международные стандарты серии ISO 9241-12-98. «Эргономические требования по работе в офисе с терминалами визуального отображения информации».

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

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

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

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

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

Система должна оборудоваться в соответствии с Санитарными правилами и нормами — СанПиН 2.2.2/2.4.1340-03 — Гигиенические требования к персональным электронно-вычислительным машинам и организации работы (Утв. Постановлением Главного государственного санитарного врача РФ от 3 июня 2003 г. №118).

4.1.7 Требования к транспортабельности для подвижных АСТребования к транспортабельности для подвижных АС не предъявляются.

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

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

хранению компонентов Системы обеспечиваются Заказчиком.

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

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

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

Требования к срокам и периодичности проведения работ по техническому обслуживанию для Системы в целом и для каждой из подсистем определяются в «Частном техническом задании».

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

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

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

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

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

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

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

В рамках работ настоящего ТЗ дополнительных требований к регламенту обслуживания Системы не предъявляется.

4.1.9 Требования к защите информации от несанкционированного доступаВ ходе выполнения работ по модернизации Системы необходимо осуществить

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

информационной безопасности Системы в целом; оценить соответствие существующей системы информационной

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

4.1.9.1 Технические требования по защите информации

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

ручную и автоматизированную проверку кода на предмет НДВ; использование при разработке доверенной аппаратной платформы с

функциями защиты от НДВ на системном и прикладном уровне; контроль версионности исходного кода; тестирование информационной системы на проникновения (пинтесты).

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

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

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

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

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

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

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

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

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

восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

4.1.10.2 Требования к регламентам и объемам резервного копирования и архивирования данных

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

архивной копии (архивные копии log-файлов).Периодичность и очередность этих операций определяются отдельным

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

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

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

Технические и организационные мероприятия по резервному копированию обеспечиваются Заказчиком.

4.1.11 Требования к патентной чистоте

4.1.11.1 Перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей

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

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

Разработанный программный код, по требованиям настоящего ТЗ, - является собственностью Заказчика.

4.1.11.2 Требования к использованию лицензионного программного обеспечения

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

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

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

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

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

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

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

4.1.13 Дополнительные требования

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

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

4.1.13.2 Требования к Системе, связанные с особыми условиями эксплуатации

Требования к системе, связанные с особыми условиями эксплуатации, не предъявляются.

4.1.13.3 Требования по сертификации Системы, ее компонентов

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

4.1.13.4 Специальные требования

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

Технические средства, необходимые для размещения разрабатываемого решения, предоставляются Заказчиком.

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

4.1.14 Требования к электронным учебным курсам

4.1.14.1 Требования по соответствию электронных курсов международным стандартам

Электронные учебные курсы должны полностью соответствовать требованиям стандарта SCORM 2004. (Разработчик стандарта Advanced Distributed Learning (ADL) http://www.adlnet.org/).

Согласно требованиям SCORM 2004, электронные учебные курсы должны содержать три основных компонента:

язык взаимодействия программ (run-time communications) — стандартный язык, на котором обучающая программа «общается» с системой дистанционного обучения (СДО);

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

файл-манифест / пакет содержания (Content package). Этот файл содержит полное описание курса обучения и составляющих его файлов. Документ (The manifest) о Едином пакете содержания (Content Packages) SCORM описывается через Extensible Markup Language (XML) (файл“imsmanifest.xml”).

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

К формату используемых в курсе файлов предъявляются следующие требования: возможность вставки в курсы любого Rich-media содержимого:

Macromedia® Flash®, Shockwave®, Java®, видео в форматах (AVI, WMV, MPEG, MOV, RM, FLV);

простые механизмы вставки и синхронизации звукового сопровождения в форматах: AIFF, WMA, MP3, WAV, SWF;

Присоединяемые внешние документы могут быть: Текстовый файл (TXT), HTML файл, Rich Text Format (RTF), Microsoft Word (DOC), Microsoft Excel (XLS), Adobe PDF, Архив ZIP, Архив RAR и т. д.

4.1.14.3 Требования к просмотру электронных курсов через браузер

Электронные курсы в полном объеме и с полным функциональным наполнением должны просматриваться в браузере Google Chrome 49 и выше.

Требования к тиражированию

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

Требования к тиражированию представлены в пункте 4.2.2.

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

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

Информация о подсистемах и модулях, которые были изменены или созданы в рамках развития Системы, представлена в таблице 9.

Таблица 9 — Работы, выполняемые в рамках развития Системы

№ п.п.

Подсистема Тип выполняемых работ

Модуль Пункт ТЗ

1. Подсистема приема и обработки сообщений

Увеличение функциональности существующей подсистемы

Модуль управления обращениями

4.2.1.1.1

2. Модуль управления КСиП 4.2.1.1.2

3. Модуль управления привлекаемыми ресурсами, силами и средствами

4.2.1.1.3

4. Модуль управления обращениями

4.2.1.1.4

5. Модуль ведения единого телефонного справочника

4.2.1.1.5

6. Модуль обработки сигналов из смежных систем

4.2.1.1.6

7. Модуль организации телефонной связи

4.2.1.1.7

8. Геоинформационная интеграционная подсистема

Увеличение функциональностисуществующей подсистемы

- 4.2.1.2

9. Подсистема интеграции данных

Увеличение функциональности существующей подсистемы

- 4.2.1.3

10. Подсистема информационно-аналитического сопровождения

Создание новой подсистемы и соответствующих модулей

Модуль формирования и тиражирования регламентированных отчетов

4.2.1.4.1

11. Модуль хранения 4.2.1.4.2

статистических данных

12. Модуль формирования динамических отчетов

4.2.1.4.3

13. Подсистема комплексного мониторинга и управления

Создаваемая подсистема взамен подсистемы комплексного мониторинга

Модуль управления инфраструктурой

4.2.1.5.1

14. Подсистема обеспечения информационной безопасности

Увеличение функциональности существующей подсистемы

Модуль управления доступом к информационным ресурсам

4.2.1.6

15. Подсистема поддержки принятия решений

Увеличение функциональности существующей подсистемы

Модуль анализа и прогнозирования кризисных ситуаций

4.2.1.7.1

16. Модуль управления диалогами

4.2.1.7.2

17. Отчетно-аналитический модуль

4.2.1.7.3

18. Модуль контроля исполнения поручений

4.2.1.7.4

19. Разработка нового модуля

Модуль ведения реестра ресурсов сил и средств

4.2.1.7.5

20. Подсистема управления справочниками и классификаторами

Увеличение функциональности существующей подсистемы

- 4.2.1.8

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

Увеличение функциональности существующей подсистемы

Модуль «Открытый портал» 4.2.1.9.1

22. Подсистема электронного взаимодействия с должностными лицами

Увеличение функциональности существующей подсистемы

Модуль «Закрытый портал» 4.2.1.10.1

23. Подсистема электронного документооборота

Создаваемая подсистема

Модуль отчетности 4.2.1.11.1

24. Модуль согласования 4.2.1.11.2

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

4.2.1 Требования к функциональному развитию АПК

4.2.1.1 Требования к функциям Подсистемы приема и обработки сообщений

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

4.2.1.1.1 Требования к функциям модуля управления обращениями

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

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

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

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

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

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

4.2.1.1.1.3 Требования к функции обработки обращений граждан

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

4.2.1.1.2 Требования к функциям модуля управления КСиП

Модуль должен реализовывать следующие функции: создание карточки КСиП на основе обращений граждан; создание карточки КСиП на основе события из смежной системы; делегирование карточки КСиП целиком; делегирование задач плана реагирования при обработке КСиП; рассылка связанной с КСиП информации; постановка КСиП на контроль; получение карточек КСиП из системы диспетчеризации 112; отображение связанных с КСиП камер; объединение карточек КСиП; прогнозирование развития КСиП;

отображение заданного числа карточек КСиП.

4.2.1.1.2.1 Требования к функции создания карточки КСиП на основе обращений граждан

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

При создании карточки КСИП на основании обращения, должна проставляться ссылка. В обращении на соответствующую карточку и наоборот.

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

4.2.1.1.2.2 Требования к функции создания карточки КСиП на основе события из смежной системы

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

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

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

4.2.1.1.2.3 Требования к функции делегирования карточки КСиП целиком

Должен быть реализован функционал назначения ответственного за обработку карточки КСиП.

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

4.2.1.1.2.4 Требования к функции делегирования задач плана реагирования при обработке КСиП

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

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

4.2.1.1.2.5 Требования к функции рассылки связанной с КСиП информации

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

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

SMS шлюз необходимый для рассылки сообщений и почтовый сервер предоставляет Заказчик.

4.2.1.1.2.6 Требования к функции постановки КСиП на контроль

Должна быть реализована возможность постановки КСиП на контроль пользователем системы.

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

SMS шлюз необходимый для рассылки сообщений и почтовый сервер предоставляет Заказчик.

4.2.1.1.2.7 Требования к функции получения карточек КСиП из Системы-112

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

4.2.1.1.2.8 Требования к функции отображения связанных с КСиП камер

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

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

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

4.2.1.1.2.9 Требования к функции объединения карточек КСиП

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

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

4.2.1.1.2.10 Требования к функции прогнозирования развития КСиП

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

4.2.1.1.2.11 Требования к отображению заданного числа карточек КСиП

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

4.2.1.1.3 Требования к функциям модуля управления привлекаемыми ресурсами, силами и средствами

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

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

привлечение ресурсов, сил и средств.

4.2.1.1.3.1 Требования к функции поиска доступных ресурсов сил, и средств

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

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

4.2.1.1.3.2 Требования к функции привлечения ресурсов, сил и средств в процесс реагирования

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

При обработке карточки КСиП должен быт реализован функционал выбора ПВР для размещения граждан с контролем заполненности/вместимости.

Должна быть реализована возможность внесения информации о заполненности ПВР.

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

Должно быть реализовано отображение вовлеченных в обработку происшествия сил и средств в карточке КСиП.

Для вовлеченных в реагирование сил и средств должны в автоматизированным режиме по запросу пользователя формироваться путевые листы (относительно проблем, связанных с ЖКХ, например, отсутствие горячей воды).

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

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

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

Модуль ведения единого телефонного справочника должен реализовывать следующие функции:

ведение реестра служебных и иных контактных телефонных номеров организаций и ответственных лиц;

оперативный доступ пользователей системы к контактным данным, с поддержкой поиска;

предоставление списка кратких карточек контактов.

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

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

при достижении определенных условий (превышение ПДК).

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

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

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

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

телефонных номеров с ведением истории вызовов абонентов.Оборудование IP телефонии предоставляется Заказчиком.

4.2.1.2 Требования к функциям Геоинформационной подсистемы

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

отображение на карте сил и средств, связанных с объектами позиционирования ГЛОНАСС/GPS;

отображение на карте сил и средств, вовлеченных в процесс реагирования по конкретному КСиП;

отображение на карте объектов управления: шлагбаумы и гидранты; отображение на карте объектов типа трансформаторная подстанция с

возможностью просмотра информации по состоянию объекта, на основании данных от внешней системы;

автономное функционирование, без связи с ГеоИС; автоматическую загрузку данных с ГеоИС.

4.2.1.3 Требования к функциям Подсистемы интеграции данных

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

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

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

системы мониторинга электростанций в части получения информации о состоянии объектов.

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

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

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

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

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

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

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

Функции разрабатываемых модулей представлены в пунктах 4.2.1.4.1-4.2.1.4.3.

4.2.1.4.1 Требования к функциям модуля формирования и тиражирования регламентированных отчетов

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

формирование сводного отчета об обстановке в МО, с возможностью корректировки данных;

формирование отчетов в вышестоящие инстанции (Администрация, ЦУКС), с возможностью корректировки данных;

формирование отчетов по ТСД (1/ЧС-5/ЧС) на основе данных, полученных в ходе формирования карточки происшествия, дополнения карточки происшествия данными по ходу реагирования, данными обстановки;

формирование и редактирование отчетных форм для подготовки решений, протоколов, распоряжений КЧС (отчетные формы должны быть спроектированы на этапе технического проекта для каждого МО).

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

4.2.1.4.2 Требования к функциям модуля хранения статистических данных

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

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

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

сведения об обращениях граждан; справочники и классификаторы (при изменении).

4.2.1.4.3 Требования к функциям модуля формирования динамических отчетов

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

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

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

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

Модуль должен реализовывать следующие функции: отображение текущего состояния шлагбаума (с уведомлением о

неработоспособности); открытие и закрытия шлагбаума из интерфейса системы (доступ к

необходимым данным и интеграциям обеспечивает Заказчик Исполнителю на этапе технического проектирования);

создание карточки КСиП для ремонта шлагбаума с необходимыми поручениями (полный перечень поручений предоставляется Заказчиком Исполнителю на этапе технического проектирования).

4.2.1.6 Требования к функциям Подсистемы обеспечения информационной безопасности

Данная подсистема развивается взамен в связи с расширением функционала, связанного с управлением доступом к информационным ресурсам.

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

Модуль управления доступом к информационным ресурсам должен реализовывать следующие функции:

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

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

4.2.1.7 Требования к функциям Подсистемы поддержки принятия решений

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

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

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

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

Рисунок 4 — Пример отображения информации о землетрясениях

Рисунок 5 — Пиковое ускорение грунта

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

основании данных от смежных систем; прогнозирования подтоплений на основе данных от гидропостов:

определение вовлеченных в происшествие критических и социально важных объектов, на основании данных о таких объектах от внешних систем;

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

расчет и отображение пользователю информации о возможном числе пострадавших;

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

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

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

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

Доступность внешних систем, необходимый формат и качество данных обеспечивается Заказчиком.

4.2.1.7.2 Требования к функциям модуля управления диалогами

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

опрос абонента по сценарию; уведомление оператора о вероятности ложного вызова.

4.2.1.7.2.1 Требования к функции опроса абонента по сценарию

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

На основании данных опроса абонента должно регистрироваться обращение гражданина в подсистеме приема и обработки сообщений.

При обращении гражданина по телефону должна вестись аудиозапись разговора. Аудиозапись должна прикрепляться к регистрируемому обращению.

Должно быть реализовано динамическое заполнение формы в соответствии с опросниками абонента по заранее определенным сценариям (система детерминированных диалогов). Форма должна отображаться автоматически, после приема вызова оператором в интерфейсе АПК БГ.

Должно быть реализовано автозаполнение известных данных, в случае если абонент звонил ранее.

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

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

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

4.2.1.7.3 Требования к функциям отчетно-аналитического модуля

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

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

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

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

4.2.1.7.5 Требования к функциям модуля ведения реестра ресурсов, сил и средств

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

ведение реестра личного состава; ведение реестра техники; ведение реестра ресурсов; ведение реестра ПВР.

4.2.1.7.5.1 Требования к функции ведения личного состава

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

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

личного состава.

4.2.1.7.5.2 Требования к функции ведения реестра техники

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

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

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

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

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

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

соответствии с методическими рекомендациями по созданию, хранению, использованию и восполнению резервов материальных ресурсов для ликвидации чрезвычайных ситуаций природного и техногенного характера (утв. МЧС России 10.08.2018 № 2-4-71-18-14):

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

4.2.1.7.5.4 Требования к функции ведения реестра ПВР

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

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

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

4.2.1.8 Требования к функциям Подсистемы управления справочниками и классификаторами

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

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

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

4.2.1.9.1 Требования к функциям модуля «Открытый портал»

Под открытым порталом подразумевается сегмент АПК БГ находящийся в открытом контуре и доступный для граждан региона.

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

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

на карте.

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

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

адрес электронной почты; номер мобильного телефона. ЕСИА.

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

4.2.1.9.1.2 Требования к функции ведения личных кабинетов граждан

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

просмотр истории обращений, с возможностью просмотреть информацию по обращениям и создать новое обращение;

просмотр/редактирование личных данных; настройка получаемых уведомлений.

4.2.1.9.1.3 Требования к функции подачи обращений граждан

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

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

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

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

Граждане должны иметь возможность получить на открытом портале следующую информацию:

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

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

на картографической основе в виде многоугольников, линейных и точечных объектов.

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

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

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

4.2.1.10 Требования к функциям Подсистемы электронного взаимодействия с должностными лицами

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

4.2.1.10.1 Требования к функциям модуля «Закрытый портал»

Модуль должен обеспечить муниципальные службы инструментами публикации данных на открытом портале и возможность участия в процессах реагирования без установки полноценного АРМ АПК БГ.

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

(приложения №1, 2,); раздел строевая записка «пожарная охрана», (приложения №3-1, 3-2, 3-

3).

4.2.1.10.1.1 Требования к функции авторизации пользователей

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

Закрытый портал должен быть опубликован по https с действующим сертификатом.Доступ должен быть обеспечен без применения VipNET.

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

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

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

4.2.1.10.1.3 Требования к функции доступа к карточкам КСиП в процессах реагирования;

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

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

4.2.1.10.1.4 Требования к функции внесения данных о текущей обстановке

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

4.2.1.10.1.5 Требования к функции подачи информационных справок

Должна быть реализована возможность подачи информационных справок с использованием «Закрытого портала».

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

4.2.1.11 Требования к функциям Подсистемы электронного документооборота

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

Данная подсистема должна состоять из следующих модулей: модуль отчетности; модуль согласования.

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

4.2.1.11.1 Требования к разделу «Строевая записка «пожарная охрана»

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

Список сведений (вкладок), которые должны быть сформированы: строевая записка – локальная (Приложение В). Формируется в каждом

пожарном отряде / пожарной части, в последствии сводится на 1 страницу для ЦУКС;

соблюдение расписания выезда (Приложение В). Формируется в каждом пожарном отряде / пожарной части. В последствии сводится на 1 страницу для ЦУКС. Обязательно указываются РТП, должна быть возможность перехода на сведения по РТП;

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

сводный «Техника и личный состав» (Приложение В). Указывается количественно по каждому показателю;

реестр РТП – указывается список личного состава, с указанием: муниципального района, гарнизона, ПСЧ, должности, реквизитов приказа о допуске к РТП и ПАСР (+скан копия приказа), дата окончания действия свидетельства на допуск к РТП и ПАСР, результат допуска на текущую дату (годен, просрочен).

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

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

Должна быть возможность контроля по времени, если к назначенному времени сведения не представлены, то в сводном отчете данное МО и ПЧ подсвечиваются как «сведений нет».

4.2.1.11.2 Требования к функциям модуля отчетности

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

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

отправка отчетов в вышестоящие инстанции; контроль статуса обработки отчета; обработка отчета вышестоящими инстанциями.

4.2.1.11.3 Требования к функциям модуля согласования

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

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

корректировку; формирование отчетов на основе информации из информационных

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

4.2.2 Требования к тиражированию КСА ЕЦОРДолжно быть проведено тиражирования функционала КСА ЕЦОР на следующие

городские округа: Холмский городской округ; Долинский городской округ.

В каждом городском округе должен быть развернут и настроен полнофункциональный экземпляр КСА ЕЦОР, учитывающий следующие особенности:

географическое положение; перечень и регламенты работы диспетчерских служб; особо важные объекты на территории городского округа.

Перечень необходимых мероприятий по адаптации КСА ЕЦОР должен быть определен на этапе обследования каждого городского округа.

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

4.2.2.1 Дополнительные требования по тиражированию в Долинском ГО

4.2.2.1.1 Интеграция с внешними системами

В рамках работ по тиражированию КСА ЕЦОР, должна быть интегрирована система видеонаблюдения.Разработчик: ООО «Ай Ти Ви групп»Версия ПО Интеллект v4.10.3.2764В состав входят 13 купольных видео камер, 1 стационарная.Территориально располагается: г. Долинск ул. Комсомольская 37 (здание администрации).

4.2.2.1.2 Организации, подключаемые к ЕЦОР

В Долинском МО к ЕЦОР должны быть подключены, приведенные в таблице 10.

Таблица 10 — Организации, подключаемые к ЕЦОР№ п/п

Название организации Адрес месторасположения

1 ЕДДС МО ГО «Долинский» Комсомольская ул., 37, Долинск

2МУП «Теплоснабжающая организация»

Бумажная ул., 2, Долинск

3 ГУП «Долинское ДРСУ» ул. Кирова, 77, Долинск

4МБУ «Управление городским хозяйством»

Пионерская ул., 7, Долинск

5ООО «РСО Универсал» (Водоканал)

просп. Победы, 23, Долинск

6 МУП «Электросервис» Комсомольская ул., 37, Долинск

7Долинский сетевой район ФРС ПАО «Сахалинэнерго»

ул. Ленина, 105, г. Южно-Сахалинск

8ОСП «Долинский пожарный отряд»

ул. Хабаровская, 18, Долинск

9ГБУЗ «Долинская ЦРБ» отделение скорой медицинской помощи) (ул.

Пионерская, 10-А, Долинск

10

ОМВД России по городскому округу «Долинский»

Комсомольская ул., 23, Долинск

11МКУ «Производственно-техническое объединение»

ул. Комсомольская, 37, Долинск

Для формирования сведений отчетов по температурному режиму, поставки и расходу топлива, - необходимо разработать форму ввода на клиенте п. 4.2.1.10.1. «Требования к функциям модуля «Закрытый портал» настоящего ТЗ, для организаций, приведенные в таблице 11.

Таблица 11 — Организации, для которых необходимо разработать форму ввода на клиенте (отчет по температурному режиму)№ п/п

Название организации Адрес месторасположения

1 Котельная №2 с. Сокол2 Котельная №7 с. Сокол3 Котельная №8 с. Сокол4 Котельная №11 с. Сокол5 Котельная №1 с. Взморье6 Котельная №13 с. Покровка7 Котельная г. Долинск8 Котельная с. Быков9 Котельная с. Стародубск10 Котельная №1 с. Советское11 Котельная №103 с. Советское12 Котельная №14 с. Советское13 Котельная с. Углезаводск14 Мини ТЭЦ г. Долинск15 Котельная ТЭЦ г. Долинск

Для формирования сведений по поставке и расходу топлива необходимо разработать форму ввода на клиенте п. 4.2.1.10.1. Требования к функциям модуля «Закрытый портал» настоящего ТЗ, для организаций, приведенных в таблице 12.

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

Название организации

1 ООО ЖилКомСервис2 ООО Жилсервис3 МУП Теплоснабжающая компания4 ООО Быков тепло5 ООО Комфорт плюс6 ООО Стародубской ЖКХ

4.2.2.2 Дополнительные требования по тиражированию в Холмском ГО

4.2.2.2.1 Интеграция с внешними системами

В рамках работ по тиражированию КСА ЕЦОР, должна быть интегрирована система видеонаблюдения TRASSIR.

Разработчик: «DSSL»Версия ПО TRASSIR 4.0-9632.В состав входят 45 видео камер.Территориально располагается: г. Холмск, ул. Некрасова 2.

4.2.2.2.2 Организации, подключаемые к ЕЦОР

В Холмском МО к ЕЦОР должны быть подключены организации, приведенные в таблице 13.

Таблица 13 — Организации, подключаемые к ЕЦОР№ п/п

Название организации Адрес месторасположения

ЕДДС МО «Холмский ГО» г. Холмск, ул. Некрасова 2ОМВД России по Холмскому округу Школьная ул., 27, ХолмскОтделение скорой медицинской помощи ГБУЗ «Холмская ЦРБ»

Советская ул., 103, Холмск

ПСЧ «1 отряд ФПС по Сахалинской области» (гарнизон в целом)

Советская ул., 110, планировочный район Ново-Александровск, Южно-Сахалинск

МУП «Тепло» Портовая ул., 14, ХолмскМУП «Водоканал» Портовая ул., 11А, ХолмскМУП «Горэлектросеть» ул. Лермонтова, 26, ХолмскМБУ «УГДХ» МО «Холмский городской округ»

Капитанская ул., 9, Холмск

ГУП СО «Дорожник» Железнодорожная ул., 94, ХолмскЮЗБСР ФРС ПАО «Сахалинэнерго» площадь Ленина, 6, Холмск

Для формирования сведений отчетов, - необходимо разработать форму ввода на клиенте п. 4.2.1.10.1. «Требования к функциям модуля «Закрытый портал» настоящего ТЗ, для организаций, приведенных в таблице 4.

Таблица 14 — Организации, для которых необходимо разработать форму ввода на клиенте (формирование сведений отчетов)№ Наименование организации Адрес диспетчерской

1

МКУ «Управление по делам гражданской обороны и чрезвычайным ситуациям» муниципального образования «Холмский городской округ»

Некрасова 2

2Администрация муниципального образования «Холмский городской округ»

пл. Ленина 4

3 ОМВД Росси по Холмскому городскому округу Школьная 27

4Холмский ЛОП Сахалинского ЛО МВД России на транспорте

ул. Советская 119

5 3 ПСЧ «1 отряд ФПС» по Сахалинской области» ул. Советская 816 ПЧ-10 ОКУ «Чеховский пожарный отряд» п.Чехов ул. Ленина 57

7ПЧ-11 ОСП Чеховский пожарный отряд с. Яблочное

п. Яблочное ул.Центральная 108

8Отделение скорой медицинской помощи ГБУЗ «Холмская ЦРБ»

ул. Советская 93-а

9УФСБ по Сахалинской области, отдел в г. Холмске г. Холмск, Школьная улица, 26

10 Холмский таможенный пост ул. Портовая 4

11 ОАО «Сахалинское морское пароходство» ул. Победы 18-а

12Р/к имени В.И. Ленина п. /Яблочное ул. Центральная 98

13 ПАО «Холмский морской торговый порт» ул. Советская 41

14Отделение пограничного контроля Сахалинского Управления береговой охраны ФСБ России

ул. Советская 37

15 Сахалинская ж/д станция «Холмск» Поляково16 ООО «Холмская автотранспортная компания» ул. Железнодорожная 9317 ГУП «Дорожник» ул. Железнодорожная 94

18МБУ «Управление городским дорожным хозяйством»

ул. Первомайская, 2

19ЛТЦ Холмский район Сахалинского филиала ПАО «Ростелеком»

пл. Ленина д.5

20 ЮЗБСР (юго-западный базовый сетевой район) ул. Пушкина 36-а21 МУП «Горэлекторосеть» ул. Лермонтова 2622 МУП «Водоканал» ул. Портовая 11-а

23 МУП «Тепло» Капитанская 12

24 МУП «Муниципальная управляющая компания» ул. Первомайская 225 ООО «Тепловые сети» п. Чехов ул. Луговая 10

26

ООО «Портовая», ООО «Южная», ООО «Северная»

ул. Комсомольская 9

27 ООО «Управляющая компания Холмск» ул. Советская 146-а28 ООО «Комфорт» п. Яблочное ул. Центральная 1629 ООО «Искра», ООО «Ника плюс» п. Правда ул. Аллейка 20

30 ООО «Бастион» ул. Советская 71, офис 323/231 ООО «Холмск» ул. Советская 146-а

32ООО «Холмский Управдом»ООО «Управдом»

ул. Советская 109

33 ОАУ «Юго-Западное лесное хозяйство» п. Костромское ул. Холмская 2

34ГКУ «Сахалинские лесничество», филиал «Холмское лесничество»

п. Костромское ул. Холмская 2

35 МГ-II (метеостанция) ул. Макарова 1

36

ФГУЗ «Центра гигиены и эпидемиологии по Сахалинской области в Холмском и Невельском районах»

г. Холмск, ул. Железнодорожная, 24

37

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

г. Холмск, ул. Железнодорожная, 24

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

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

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

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

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

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

Информационное обеспечение Системы состоит из внутримашинной и внемашинной информационных баз.

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

4.3.2.1 Требования к составу, структуре и способам организации данных в системе

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

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

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

должны быть определены на этапе Технического проекта и приведены в документе «Пояснительная записка к техническому проекту».

4.3.2.2 Требования к организации ввода данных в систему

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

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

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

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

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

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

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

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

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

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

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

4.3.2.4 Требования по применению систем управления базами данных

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

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

Общие требования к используемой реализации СУБД: поддержка реляционной или объектно-реляционной модели базы

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

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

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

4.3.2.6 Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

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

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

4.3.2.7 Требования к контролю, хранению, обновлению и восстановлению данных

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

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

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

4.3.2.8 Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами АС

Требования не предъявляются.

4.3.3 Требования к лингвистическому обеспечениюВсе экранные формы, выходные формы, инструкции по работе и вся документация

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

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

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

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

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

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

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

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

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

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

операционная система MS Windows 7, 8, 10 и выше; установленный продукт Google Chrome 56.x и выше.

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

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

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

технических средств и общесистемной инфраструктуры в пределах требований к техническому обеспечению.

К обеспечению качества ПО предъявляются следующие требования: функциональность должна обеспечиваться выполнением подсистемами

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

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

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

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

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

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

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

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

хранение и резервное копирование данных; выполнение вычислительных функций и обработку данных; передачу данных.

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

4.3.6 Требования к метрологическому обеспечениюТребования к метрологическому обеспечению не предъявляются.

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

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

данных (СУБД) в части создания и ведения БД, обновления данных, обслуживания.

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

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

4.3.7.1 Необходимые линии и каналы связи

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

4.3.7.2 Среда передачи

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

4.3.7.3 Технические параметры каналов связи

Специальные требования не предъявляются.

4.3.7.4 Пропускная способность, интерфейсы, топология и т.п.

Пропускная способность каналов связи должна быть не ниже 100 Мбит/с.

4.3.8 Требования к другим видам обеспеченияТребования к другим видам обеспечения не предъявляются.

5 Состав и содержание работ по развитию системы

5.1 Этапы работЭтапы проведения работ по модернизации Системы приведены в таблице 15.

Таблица 15 — Этапы проведения работ по модернизации Системы

№ этапа

Наименование и содержание выполняемых работ

Отчетная документация Сроки выполнения

Финансирование этапа

1. Этап.1. Технический проект

1.1 Техническое проектирование

1 Частное техническое задание;

2 Пояснительная записка к техническому проекту;

3 Описание автоматизируемых функций;

4 Описание программного обеспечения;

5 Описание информационного обеспечения;

6 Описание архитектуры;

7 Ведомость машинных носителей информации;

8 Акт сдачи-приемки выполненных работ (1 этап)

40 календарных дней с даты, следующей за датой заключения Договора

12% от стоимости работ по Государственному Договору

2. Этап 2. Рабочая документация и ввод в действие

№ этапа

Наименование и содержание выполняемых работ

Отчетная документация Сроки выполнения

Финансирование этапа

2.1 Рабочее проектирование

1 Общее описание Системы;

2 Регламент информационного взаимодействия между участниками информационного взаимодействия;

3 Руководство пользователя;

4 Руководство администратора;

5 Руководство программиста;

6 Массив входных данных;

7 Каталог базы данных;

8 Состав выходных данных;

9 Инструкция по формированию и ведению базы данных (набора данных);

10 Программа и методика предварительных испытаний;

11 План опытной эксплуатации;

12 Программа и методика приемочных испытаний;

13 Ведомость машинных носителей информации;

14 Акт о выполнении пуско-наладочных работ.

235 календарных дней с даты завершения 1 этапа

78% от стоимости работ по Государственному Договору

№ этапа

Наименование и содержание выполняемых работ

Отчетная документация Сроки выполнения

Финансирование этапа

2.2. Разработка учебной программы

1 Учебная программа электронного учебного курса

2.3. Разработка учебно-методических материалов электронных учебных курсов

1 Дистрибутив электронного учебного курса

2.4 Проведение обучения пользователей

1 Отчет о проведении обучения пользователей.

2.5 Проведение предварительных испытаний

1 Протокол предварительных испытаний;

2 Акт о готовности к опытной эксплуатации;

2.6 Проведение опытной эксплуатации

1 Акт приемки в опытную эксплуатацию;

2 Отчет о проведении опытной эксплуатации;

3 Журнал опытной эксплуатации;

4 Акт о завершении опытной эксплуатации и допуске системы к приемочным испытаниям;

№ этапа

Наименование и содержание выполняемых работ

Отчетная документация Сроки выполнения

Финансирование этапа

2.7 Проведение приемочных испытаний

5 Протокол приемочных испытаний;

6 Акт приемки в промышленную эксплуатацию;

7 Ведомость машинных носителей информации;

8 Программное обеспечение Системы (исходные коды);

9 Акт сдачи-приемки выполненных работ ( 2 этап).

3 Тиражирование 1 Отчет о тиражировании Системы в МО Холмск и Долинск

2 Акт сдачи-приемки выполненных работ (3 этап).

10 календарных дней с даты завершения 2 этапа

10% от стоимости работ по Государственному Договору

5.2 Дополнительные сведения Дополнительные требования не предъявляются.

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

6.1 Виды, состав, объем и методы испытаний системы и ее составных частейИспытания должны быть организованы и проведены в соответствии с ГОСТ 34.603-

92 «Информационная технология. Виды испытаний автоматизированных систем».Должны быть проведены следующие виды испытаний:

предварительные испытания; опытная эксплуатация; приемочные испытания.

В состав испытаний Системы должны быть включены проверки соответствия Системы требованиям ТЗ и условиям Договора:

полноты и качества реализации функций, указанных в ТЗ; комплектности Системы; комплектности и качества документации.

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

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

Объем и методы предварительных и приемочных испытаний должны определяться соответствующей «Программой и методикой испытаний».

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

6.2 Общие требования к приемке работ по стадиямПриемка результатов работ должна осуществляться поэтапно в соответствии с

календарным планом выполнения работ по Договору.Приемка результатов выполнения работ по этапам должна быть оформлена Актами

сдачи-приемки выполненных работ (по каждому из этапов). Основанием для составления и подписания Акта сдачи-приемки выполненных работ по отдельному этапу является передача Исполнителем результатов работ в соответствии с условиями Договора.

Техническая и эксплуатационная документация и другие результаты работ должны быть переданы Заказчику:

в комплектности, определенной разделом 5 настоящего Технического задания,

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

в порядке оформления и предъявления Заказчику, определенных в подразделе 1.11 настоящего Технического задания.

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

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

Результаты проведения испытаний должны быть зафиксированы в соответствующих Протоколах испытаний. Как недостатки реализации оформляются исключительно выявленные отклонения от настоящего ТЗ или «Частного технического задания». Прочие недостатки могут документироваться как желательные доработки. Наличие желательных доработок не влияет на процесс передачи в эксплуатацию.

По завершении предварительных и приемочных испытаний должны быть оформлены соответствующие Акты, содержащие вывод о соответствии Системы предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, данных комиссией в ходе испытаний. Результаты опытной эксплуатации должны быть отражены в «Отчете о проведении опытной эксплуатации» и «Журнале опытной эксплуатации» и рассмотрены в ходе приемочных испытаний.

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

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

6.3 Сведения о гарантийном обслуживании системыГарантийный срок составляет 12 (двенадцать) месяцев с даты подписания

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

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

Исполнитель не гарантирует отсутствие недостатков или сбоев в процессе работы, возникающих по причине несоответствия оборудования или установленного на рабочем месте программного обеспечения конечного пользователя требованиям, предъявляемым к характеристикам клиентских мест (см. пункт 4.3.4. «Требования к программному обеспечению»).

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

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

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

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

Программа и методика предварительных испытаний; Программа и методика приемочных испытаний.

Сроки устранения замечаний и рекомендаций, данных приемочной комиссией в ходе испытаний, определяются в «Акте приемки в промышленную эксплуатацию».

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

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

6.5 Статус приемочной комиссииСтатус приемочной комиссии: ведомственная.

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

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

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

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

7.1 Развертывание и конфигурированиеСистема должна быть установлена Исполнителем на оборудовании,

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

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

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

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

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

7.2 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМДля приведения поступающей в Систему информации к виду, пригодному для

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

Исполнителем должны быть описаны и Заказчиком утверждены вновь вводимые справочники и классификаторы.

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

В случае необходимости Исполнитель должен обеспечить ручной ввод исходных данных в Cистему в случае отсутствия этих данных в электронном виде на машинных носителях.

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

7.3 Изменения, которые необходимо осуществить в объекте автоматизации

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

необходимости ее изменения.

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

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

объекте автоматизации должен быть уточнен на стадии Технического проекта и приведен в документе «Пояснительная записка к техническому проекту».

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

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

Обучение персонала должно проводиться Исполнителем по разработанным руководствам, электронным учебным курсам, подготовленным согласно разделу 4.1.14 настоящего ТЗ и документу «Учебная программа электронного учебного курса».

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

По завершении обучения должен быть оформлен «Отчет о проведении обучения пользователей».

8 Требования к документированиюТехническая и эксплуатационная документация на Систему (далее — документы на

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

ГОСТ 34.003-90 — в части терминологии; ГОСТ 34.201-89, ГОСТ 19.101-77, 19.103-77 — в части наименования и

обозначения документов; ГОСТ 34.601-90 — в части определения стадий и этапов работ; ГОСТ 34.602-89 — в части состава, содержания и правил оформления

документов «Техническое задание», «Частное техническое задание». ГОСТ 34.603 -92 — в части определения видов испытаний; РД 50-34.698-90 — в части структуры и содержания документов.

Документы на Систему должны оформляться в соответствии с требованиями ГОСТ 2.105-95 на листах формата А4 по ГОСТ 2.301-68 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания.

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

в части ПО Системы должен содержать исчерпывающее описание ПО ГОСТ 19.ХХХ, обеспечивающее его установку, настройку, эксплуатацию и сопровождение;

в части комплекса технических средств (КТС) Системы должен содержать исчерпывающее описание КТС по ГОСТ 34.ХХХ, обеспечивающее развертывание ПО Системы, а также сопровождение КТС Системы.

Формальное полное соответствие документов на Систему требованиям РД 50 34.698-90 и ГОСТ 19.ХХХ по составу и структуре разделов не требуется. При этом должно быть достигнуто адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы по всем позициям, определяемым РД 50-34.698-90 и ГОСТ 19.ХХХ для отдельных документов.

Документам на Систему должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-89, ГОСТ 19.101-77-82, ГОСТ 19.103-77.

Состав документации на Систему по стадиям и этапам определен в Разделе 5.Документ «Регламент информационного взаимодействия между участниками

информационного взаимодействия» (далее — Регламент) должен быть расширен в части взаимодействия с внешними информационными системами и содержать разделы:

общая часть: назначение, основание разработки и применения, область

применения; объекты регулирования Регламента: определение субъектов,

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

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

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

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

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

Алгоритмы действий для КСиП на каждое МО, должны быть оформлены отдельными приложениями регламента взаимодействия, в последствии загружены в Систему.

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

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

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

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

аппаратные платформы, в том числе: промышленные и тестовые среды, ресурсы и их размещение, система хранения;

резервное копирование; системное программное обеспечение; межсетевое взаимодействие; таблица доступов администраторов.

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

9 Источники разработки

9.1 Нормативно-правовые актыПри развитии Системы должны быть использованы следующие нормативные,

правовые, методические документы и документы по стандартизации:Доктрины, Стратегии и Федеральные целевые программы:

Доктрина информационной безопасности Российской Федерации, утвержденная Президентом Российской Федерации от 05.12.2016 №64;

Стратегия развития информационного общества в Российской Федерации, утвержденная Президентом Российской Федерации 07.02.2008 № Пр-212;

Постановление Правительства Российской Федерации от 03.03.2012 №189 «О федеральной целевой программе «Поддержание, развитие и использованием системы ГЛОНАСС на 2012-2020 годы».

Федеральные законы и нормативные акты: Уголовный кодекс Российской Федерации; Гражданский кодекс Российской Федерации; Федеральный закон Российской Федерации от 27.12.2002 № 184-

ФЗ (ред. от 05.04.2016) «О техническом регулировании»; Федеральный закон Российской Федерации от 29.07.2004 № 98-ФЗ

(ред. от 12.03.2014) «О коммерческой тайне»; Федеральный закон от 27.07.2006 № 152-ФЗ (ред. от 21.07.2014) «О

персональных данных»; Федеральный закон Российской Федерации от 27.07.2006 (ред. от

06.07.2016) № 149-ФЗ «Об информации, информационных технологиях и о защите информации».

Государственные стандарты, регламенты и руководящие документы: ГОСТ 2.114-95. «Единая Система Конструкторской Документации.

Технические условия»; ГОСТ 19.102-77. «Единая Система Программной Документации.

Стадии разработки»; ГОСТ 34.003-90. «Информационная технология. Комплекс

стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»;

ГОСТ 34.201-89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»;

ГОСТ 34.401-90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Средства технические периферийные автоматизированных систем дорожного движения. Типы и технические требования»;

ГОСТ 34.601-90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;

ГОСТ 34-602-89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;

РД 50-680-88. «Методические указания. Автоматизированные системы. Основные положения»;

РД 50-682-89. «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения»;

РД 50-34.698-90. «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»;

ГОСТ Р 50739-95. «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования»;

ГОСТ Р 50922-2006. «Защита информации. Основные термины и определения»;

ГОСТ Р 51241-2008. «Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний»;

РД «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», решение председателя Государственной технической комиссии при Президенте Российской Федерации от 30.03.1992;

РД «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации», решение председателя Государственной технической комиссии при Президенте Российской Федерации от 25.07.1997;

РД «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия не декларированных возможностей», Приказ Председателя Государственной технической комиссии при Президенте Российской Федерации №114 от 04.06.1999;

Приказ ФСТЭК России, ФСБ России, Мининформсвязи России №55/86/20 от 13 февраля 2008 г. «Об утверждении Порядка проведения классификации информационных систем персональных данных»;

Приказ ФСТЭК России от 5 февраля 2010 г. №58 «Об утверждении положения о методах и способах защиты информации в информационных системах персональных данных»;

Приказ ФСТЭК России № 17 от 11.02.2013 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;

Приказ № 21 ФСТЭК России от 18.02.2013 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»);

Приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их

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

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

документы:1 ГОСТ Р 52155-2003 — Географические информационные системы федеральные,

региональные, муниципальные. Общие технические требования (принят и введен в действие Постановлением Госстандарта России от 9 декабря 2003 г., № 359-ст);

2 ГОСТ Р 52438-2005 — Географические информационные системы. Термины и определения (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2005 г. № 423-ст);

3 ГОСТ Р 52439-2005 — Модели местности цифровые. Каталог объектов местности. Требования к составу (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2005 г. № 424-ст);

4 ГОСТ Р 52440-2005 — Модели местности цифровые. Общие требования (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2005 г. № 425-ст);

5 ГОСТ Р 52571-2006 — Географические информационные системы. Совместимость пространственных данных. Общие требования (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 сентября 2006 г. № 214-ст);

6 ГОСТ Р 52572-2006 — Географические информационные системы. Координатная основа. Общие требования (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 сентября 2006 г. № 215-ст);

7 ГОСТ Р 52573-2006 — Географическая информация. Метаданные (утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 сентября 2006 г. № 216-ст);

8 ГОСТ 19.101-77 — «Единая система программной документации. Виды программ и программных продуктов»;

9 ГОСТ 19.103-77 — «Единая система программной документации. Обозначения программ и программных документов»;

10 ГОСТ Р ИСО 14001-98. Системы управления окружающей средой. Требования и руководство по применению;

11 ГОСТ 12.1.030-81 «Электробезопасность. Защитное заземление. Зануление»;12 ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования»;13 ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования

безопасности»;14 ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к

специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации»;

15 ГОСТ 21552-84 — «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение»;

16 ГОСТ 2.105-95 — Единая система конструкторской документации. Общие требования к текстовым документам;

17 ГОСТ 2.301-68 — Единая система конструкторской документации. Форматы;18 ГОСТ 28195-89 — Оценка качества программных средств. Общие положения;19 ГОСТ 28806-90 — Качество программных средств. Термины и определения20 ГОСТ 16504-81 — Система государственных испытаний продукции. Испытания и

контроль качества продукции. Основные термины и определения21 ГОСТ Р ИСО/МЭК ТО 12182-2002 Информационная технология (ИТ).

Классификация программных средств;22 ГОСТ Р ИСО/МЭК 12207-2010 — Информационная технология. Системная и

программная инженерия. Процессы жизненного цикла программных средств;23 ГОСТ Р ИСО/МЭК ТО 15271-2002 — Информационная технология (ИТ).

Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств);

24 ГОСТ Р ИСО/МЭК 9126-93 — Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению;

25 ГОСТ Р ИСО/МЭК 15026-2002 — Информационная технология. Уровни целостности систем и программных средств;

26 ГОСТ Р ИСО/МЭК 14764-2002 — Информационная технология. Сопровождение программных средств;

27 ГОСТ Р ИСО/МЭК ТО 9294-93 — Информационная технология (ИТ). Руководство по управлению документированием программного обеспечения;

28 ГОСТ Р ИСО/МЭК 15910-2002 — Информационная технология (ИТ). Процесс создания документации пользователя программного средства;

29 ISO/IEC 14756:1999 — Информационные технологии. Измерение и оценка эксплуатационных характеристик автоматизированных систем программного обеспечения;

30 ГОСТ 2.051-2006 — Единая система конструкторской документации (ЕСКД). Электронные документы. Общие положения;

31 ГОСТ 15.012-84 — Система разработки и постановки продукции на производство (СРПП). Патентный формуляр;

32 СанПиН 2.2.24.548-96. Физические факторы производственной среды. Гигиенические требования к микроклимату производственных помещений;

33 «Российский коммуникативный формат представления библиографических записей. Книги и сериальные издания» 1998 г.

86

Приложение А. Форма отчета «Ежедневная оперативная информация по температурному режиму в МО в период прохождения отопительного сезона»

Форма отчета «ежедневная оперативная информация по температурному режиму в МО ____________ в период прохождения

отопительного сезона».м

N

Котельная Фактическая

т, С

Температура теплоносителя Расход воды на подпитку

системы (m3/сутки)

Давление в системе

теплоснабжения

Информация об остановках, отказах

работы оборудования котельных,

водозаборов, авариях, принимаемых

мерах, количестве задействованных

сил, сроках запуска систем в работу.

По норме

подача/обратка

фактически

подача/обратк

а

По норме фактически Подающий

трубопровод

Обратный

трубопровод

Информация по поставке и расходу топлива в МО _____________________ в период прохождения отопительного сезона по состоянию на __._____.20__г.

Запас топлива

на начало

отопительного

сезона

Приход топлива Расход топлива Остаток топлива

За сутки С начала

месяца

Всего с

начала ОС

За сутки С начала

месяца

Всего с

начала ОС

В тоннах В сутках

Уголь

…

Всего уголь

Жидкое

топливо

ООО Быков

тепло

…

Всего

жидкое

топливо

Ежедневная оперативная информация по температурному режиму в МО ________ в период прохождения отопительного сезона за __.__.20__г.

Котельная Котлы в работе Среднесуточная

температура

Количество

неотапливаемых

объектов

Состояние

водоснабжения

Детальная информация об остановках, отказах работы

оборудования котельных, водозаборов, авариях,

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

сроках запуска систем в работу.

Котельная №1 (с. Советское) 1, 3 -12 0 удовлетворительн

о

88

Приложение Б. Перечень периодических отчетов ЦУКС

1. Ежемесячно к 5 числу, следующему за отчетным периодом:

1.1. Статистические показатели деятельности ЕДДС муниципального образования __________ городской округ

за февраль 2019 года

№

п/

п

Муниципал

ьное образование

При

нято

заяв

ок н

а ок

азан

ие п

омощ

и

Отр

абот

ано

заяв

окКоличество выездов подразделений ДДС на:

Про

чие

вы

езды

на

лик

вида

цию

ЧС

(про

исш

еств

ий) и

ока

зани

е по

мощ

и гр

ажда

нам

Лож

ных

выез

дов

В

резу

льта

те

деят

ельн

ости

ЕД

ДС

,

«112

» сп

асен

о че

лове

к

Все

го

Лик

вида

цию

ава

рий,

свя

занн

ых

с

АХ

ОВ

, ОВ

, РВ

Лик

вида

цию

ава

рий

на т

ранс

порт

е

Лик

вида

цию

ава

рий

на а

вто

и ж

/д

доро

гах

(сх

од с

елей

/лав

ин,

подт

опле

ний,

Л

икви

даци

ю

авар

ий

на

комм

унал

ьны

х се

тях

Лик

вида

цию

ава

рий

на э

нерг

осет

ях

Лик

вида

цию

по

след

стви

й

разр

ушен

ий с

трои

тель

ных

конс

трук

ций

Эва

куац

ию

пост

рада

вших

из

здан

ий и

соо

руж

ений

, лиф

тов

и т.

п.Л

икви

даци

ю

посл

едст

вий

Д

ТП/

всег

о Д

ТП Ока

зани

е

перв

ой

меди

цинс

кой

помо

щи

граж

дана

мО

каза

ние

пе

рвой

вр

ачеб

ной

помо

щи

(03)

Спа

сени

е на

вод

ах/ и

звле

чени

е те

л

из в

одое

мов

Про

веде

ние

по

иско

во-

спас

ател

ьны

х ра

бот

в пр

ирод

ной

сред

еС

пасе

ние

жив

отны

х

Вск

рыти

е дв

ерей

89

1.2. Режимы функционирования _________ городского округа муниципального звена Сахалинской территориальной подсистемы РСЧС

в феврале 2019 года

№

п\

п

Дата

введения

В связи, с чем введен

функционирования

(повышенная готовность,

режим ЧС)

Дата, номер,

наименование документа

Дата

снятия

Дата, номер,

наименование документа

Приме

чание

90

2. Ежеквартально, до 25 числа отчетного месяца:

2.1. Оснащенность оборудованием и оргтехникой ЕДДС муниципального образования _____________ городской округ

по состоянию на март 2019 г.

№

п/

п

Наименование

муниципального

образования

Телефонн

ая связь

Система

хранения, обработки

и передачи данных

В

КС

Си

стема

радиосвязи

Сис

тема

от

обра

жен

ия

инф

орма

ции

Сис

тема

оповещения

Сис

тема

вну

трен

ней

гро

мкой

Сис

тема

бе

спер

ебой

ного

элек

троп

итан

ия Э

Г, И

БПС

исте

ма

мони

тори

нга

тран

спор

тны

х ср

едст

в ГЛ

ОН

АС

С

Н

алич

ие м

етео

стан

ции

При

боры

РХ

Р

% о

снащ

енно

сти

При

мечание

АТС

Теле

фон

ные

аппа

раты

с

кн

опка

ми

Сис

тема

за

писи

пере

гово

ров Обо

рудо

вани

е

ЛВ

СО

бору

дова

ние

хран

ения

дан

ных

Ком

пью

теры

(кол

ичес

тво,

не

Вид

еока

мера

с ф

ункц

ией

зум

а

Вне

шни

й

УК

В

КВ

Сис

тема

опов

ещен

ия п

ерсо

нала

Сис

тема

опов

ещен

ия н

асел

ения

Проблемные вопросы ______________________________________________________________

91

2.2. Сведения о квалификации специалистов ЕДДС муниципального образования ____________ городской округ по состоянию на

февраль 2019 г.

№

п

/пНаименование

должности

Фамилия, имя,

отчество, дата рождения

Образо

вание, год

окончания

Дата,

номер приказа о

назначении на

должность

Сведения о

прохождении

обучения в УМЦ по

ГО,ЧС и ПБ, в каком

году

Номер

рабочего

телефона, с

указанием кода

города

1

.

2

.

3

.

4

.

5

.

6

.

7

.

92

8

.

93

2.3. Сведения по штатной численности специалистов ЕДДС муниципального образования __________ городской округ по состоянию на

февраль 2019 г.

№ п/п

Наименование муниципального образования

Количество специалистов ЕДДС Заработная плата (тыс. руб.) Наличие единой формы одежды

ПримечаниеВсего В ОДС средняя по МО

(по данным РОССТАТ)

начисленная, средняя ОД по

штатуфактически

по штату

фактически

94

2.4. Сведения о планируемых мероприятиях и финансовых средствах на развитие и совершенствование

ЕДДС муниципального образования ____________ городской округ по состоянию на февраль 2019 г.

№

п

/п

Проводимые

мероприятия

Финансовые средства (млн. руб.) Выделено/

реализовано фин.средств

за прошлый год (млн.руб.)

Консолидир

ованные бюджет

МО (млн.руб.)

П

римеч

ание

плани

руемые

выдел

енные

реализ

ованные

Проблемные вопросы ______________________________________________________________

95

3. Два раза в год: к 1 июня, к 1 декабря:

3.1. Сведения о нормативно-правовых актах, регламентирующих деятельность ЕДДС муниципального образования ___________

городской округ по состоянию на февраль 2019 г.

№п/п

Наименование муниципального образования

НПА о создание ЕДДС (дата, номер, название)

Полное название структурного подразделения, куда входит ЕДДС

Количество заключенных соглашений об информационном взаимодействии

рисков, характерных для территории МО

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

Проблемные вопросы ______________________________________________________________

96

3.2. Сведения о помещениях занимаемых ЕДДС муниципального образования ________ городской округ

по состоянию на февраль 2019 г.

№ п/п

Наименование муниципального образования

Площадь помещений Количество АРМ в оперативном зале Примечание Всего, м2 Оперативный

зал, м2Комната отдыха (приема пищи), м2

ОДС Глава и председатель КЧС МО

97

к 15 июня, к 15 декабря:

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

муниципального образования _______ городской округ

по состоянию на февраль 2019 г.

№ п/п

Наименование предприятия (организации)

Общее количество В дежурном варианте Наименование должности руководителя, фамилия, имя, отчество

Номер рабочего телефона, с указанием кода города

человек/бригад

техники/специальной

человек/бригад

техники/специальной

98

Приложение В. Строевая записка

99