Приложение 2 Техническое задание АСУУ

Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
Приложение к документации
Открытый запрос предложений в электронной форме
на право заключения договора
на разработку Автоматизированной
системы управления услугами (АСУУ)
Технические требования
Разработка Автоматизированной системы управления услугами (АСУУ)
МОСКВА 2013
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
Содержание
1
2
3
4
5
6
НАЗНАЧЕНИЕ ДОКУМЕНТА ...................................................................................................... 3
1.1 ВЕРСИИ ДОКУМЕНТА ......................................................................................................................... 3
ОБЩИЕ ПОЛОЖЕНИЯ .................................................................................................................. 3
2.1 ОБЛАСТЬ ПРИМЕНЕНИЯ ..................................................................................................................... 3
2.2 НОРМАТИВНЫЕ ССЫЛКИ ................................................................................................................... 3
2.3 ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ ....................................................................................... 5
ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ ........................................................... 5
ТРЕБОВАНИЯ К СИСТЕМЕ ......................................................................................................... 7
4.1 НАЗНАЧЕНИЕ СИСТЕМЫ .................................................................................................................... 7
4.2 ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ .............................................................................................................. 7
4.3 ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЬНОСТИ ............................................................................................ 9
4.4 ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ (НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ): ................................... 10
4.5 ТРЕБОВАНИЯ К ФУНКЦИЯМ СИСТЕМЫ ............................................................................................ 16
4.6 ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ ............................................................................................ 21
4.7 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ ........................................................................................... 21
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ ............................................................... 22
5.1 ВИДЫ, СОСТАВ, ОБЪЕМ И МЕТОДЫ ИСПЫТАНИЙ СИСТЕМЫ ........................................................... 22
5.2 ОБЩИЕ ТРЕБОВАНИЯ К ПРИЕМКЕ РАБОТ ПО СТАДИЯМ ................................................................... 24
УСЛОВИЯ ГАРАНТИИ ................................................................................................................ 24
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
1 Назначение документа
1.1 Версии документа
2.0
Шермаков С.А.
2.1
Стрелецкий Д.А. 10-06-2013
12-04-2013
Базовый документ
Добавлены пункты:
1.1 версионность,
4.5.3 Требования к подсистеме конфигурирования
оборудования (TR-069)
6.1.1
2.2
Стрелецкий Д.А. 23-07-2013
Условия гарантии
Изменены требования по: пиковой нагрузке, bulk
интерфейсу, доступности системы.
Добавлены пункт нагрузочного тестирования, создания
тестовой зоны.
Расширены условия гарантии.
Данные Технические требования к системам
активации услуг (далее ТТ)
устанавливают требования для реализации ключевых бизнес-процессов МРФ в области
подключения и предоставления услуг посредством систематизации и автоматизации
соответствующих бизнес процессов.
Данные ТТ вводятся в действие впервые с момента их утверждения.
2 Общие положения
2.1 Область применения
Требования данных ТТ распространяются на все макрорегиональные филиалы ОАО
«Ростелеком».
2.2 Нормативные ссылки
В данных ТТ использованы ссылки на следующие нормативные документы:
 Процедура
управления
внутренней
нормативной
документацией
ОАО «Ростелеком»;
 Процедура управления записями в ОАО «Ростелеком»;
 Инструкция по делопроизводству в ОАО «Ростелеком»;
 ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на
автоматизированные системы. Виды, комплектность и обозначение документов
при создании автоматизированных систем.
 ГОСТ 20.39.108-85 Комплексная система общих технических требований.
Требования по эргономике, обитаемости и технической эстетике. Номенклатура и
порядок выбора.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
 ГОСТ 8.256-77 Государственная система обеспечения единства измерений.
Нормирование и определение динамических характеристик аналоговых средств
измерений. Основные положения.
 ГОСТ 24.701-86 Единая система стандартов автоматизированных систем
управления. Надежность автоматизированных систем управления. Основные
положения.
 ГОСТ Р 50923-96 Дисплеи. Рабочее место оператора. Общие эргономические
требования и требования к производственной среде.
 ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на
автоматизированные системы. Виды, комплектность и обозначение документов
при создании автоматизированных систем.
 ГОСТ 34.601-90 Информационная технология Комплекс стандартов на
автоматизированные системы. Автоматизированные системы стадии создания.
 ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на
автоматизированные
системы.
Техническое
задание
на
создание
автоматизированной системы.
 ГОСТ 34.603 Информационная технология. Виды испытаний автоматизированных
систем.
 ГОСТ 12.2.007.0-75 Система стандартов безопасности труда. Изделия
электротехнические. Требования безопасности.
 ГОСТ Р 50948-2001 Средства отображения информации индивидуального
пользования. Общие эргономические требования и требования безопасности.
 ГОСТ 25861-83 Машины вычислительные и система обработки данных.
Требования электрической и механической безопасности и методы испытаний.
 ГОСТ 12.1.004-91 Система стандартов безопасности труда. Пожарная
безопасность. Общие требования.
 ГОСТ 30.001-83 Система стандартов эргономики и технической эстетики.
Основные положения.
 ГОСТ 21958-76 Система «Человек-машина». Зал и Кабины операторов. Взаимное
расположение рабочих мест. Общие эргономические требования.
 ГОСТ Р 50739-95
Средства
вычислительный
техники.
Защита
от
несанкционированного доступа к информации. Общие требования.
 ГОСТ 51275-99 Защита информации. Объект информатизации. Факторы,
воздействующие на информацию. Общие положения.
 ГОСТ 2.601-2006
Единая
система
конструкторской
документации.
Эксплуатационные документы.
 ГОСТ 19.101-77 Единая система программной документации. Виды программ и
программных документов.
 ГОСТ 2.105-95 Единая система конструкторской документации. Общие требования
к текстовым документам.
 СанПиН 2.2.2.542-96 Гигиенические требования к видеодисплейным терминалам,
персональным электронно-вычислительным машинам и организации работы.
Санитарные правила и нормы.
 СанПиН 2.2.2/2.4.1340-03 Гигиенические требования к персональным электронновычислительным машинам и организация работы. Санитарные правила и нормы.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
 СанПиН 2.2.2.1332-03 Гигиенические требования к организации работы на
копировально-множительной технике. Санитарные правила и нормы.
 НПБ 105-95 Нормы противопожарной безопасности. Определение категорий
помещений и зданий по взрывопожарной и пожарной опасности.
 ПР 50.1.024-2005 Основные положения и порядок проведения работ по разработке,
ведению и применению общероссийских классификаторов.
 Руководство по техническому учету оборудования и паспортизации сооружений
ГТС. М., "Связь", 1978.
2.3 Термины, определения и сокращения
Термин/Сокращение
Пояснение
САУ
Система Активации Услуг
АРМ
Автоматизированное рабочее место
БД
База данных
ПО
Программное обеспечение
СУБД
Система управления базой данных
ТЗ
Техническое задание
ЦОД
Центр обработки данных
АС
Система Активации Сервисов
СУЗ
Система Управления Заявками
АСР
Автоматизированная Система Расчетов – комплекс, реализующий
функции биллинга, управления отношениями с клиентами и
контроля балансов в режиме реального времени.
ПАК
Программно-Аппаратный Комплекс
Услуги телефонной связи
является аналогом существующей услуги телефонии и
факсимильной связи на базе технологий с коммутацией каналов.
Предоставляется по протоколу SIP.
Тарифный план
Базовая услуга ШПД определяющая скорость предоставления
доступа в интернет.
Сервис
Необязательное дополнение к Услуге (Например, фиксированный IP
адрес – сервис услуги ШПД)
ТЗ
Техническое Задание
3 Характеристики объекта автоматизации
Объектами автоматизации являются:

бизнес-процессы подключения/отключения, а также изменения набора и характеристик
услуг связи, предоставляемых МРФ ОАО «Ростелеком»;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования

технологические
процессы
взаимодействия
с
оборудованием,
системами
предоставления услуг и другими системами, участвующими в процессах
предоставления услуг.
Создаваемая система должна обеспечить автоматизацию процессов подключения к услугам TriplePlay по следующим технологиям абонентского доступа:
a. xDSL;
b. FTTC(PON,P2P);
c. FTTB;
d. DVBC
e. ТфОП OTA.
Для предоставления указанных выше услуг заказчик использует следующее оборудование и
системы:
Система должна обладать возможностями интеграции с распространенным сетевым
оборудованием, используемым провайдерами услуги связи. Система должна поддерживать, по
крайней мере, следующие классы оборудования:
1. АТС фиксированной и IP телефонии;
2. DSLAM;
3. MSAN;
4. OLT;
5. Голосовой шлюз;
6. Коммутатор;
7. Медиаконвертер;
8. Мультиплексор PDH;
9. Мультиплексор SDH;
10. Маршрутизатор;
11. Сервисный коммутатор;
12. IP-видеокамера;
13. Видеокодер;
14. Радиорелейная станция;
15. Оптический приемник;
Интеллектуальная платформа голосовых услуг (например Alcatel_Lucent OSP);
 Конкретный перечень оборудования, который потребуется поддерживать на момент
запуска, будет определен в ТЗ. Juniper M-серии, и E-серии;

Juniper SDX-300 (Система предоставления услуги ШПД);

Alcatel DSLAM 7300, 7302, NMS5620, AWS5523;

Siemens DSLAM 5630, 5635, Access Integrator, HiE, HiG, HiR, HiQ;

Alcatel LiteSpan-1540 и Broad Access; (Коммутаторы DSLAM.
используется для предоставления услуг по технологии ADSL.)
Оборудование
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования

D-Link DVA-G3672b;

D-Link DES-1228, DES-3200, DES-3528, DES-3552; (Коммутаторы
Используются для предоставления услуг по технологии FTTB.)

SmartLabs (Платформа для предоставления услуги IPTV)

TelecomTV (Платформа для предоставления услуги IPTV)

Cisco 7304, 7206, 5300, 5800, Catalyst 6500, 3750, 4948, 3400, 3550;

MW Orca RiGHTv;

система управления Huawei BMS N2000; (Система управления OLT)

Siemens hiQ8000, Iskratel SI3000;

Huawei OLT MA5680T;

Huawei ONT;

SoftSwitch Siemens HIQ 4200;

SoftSwitch Iskratel

Станции ТФОП типа MT-20, NEAX-SIGMA, DX-200, 5ESS, EWSD.

ASC TR-069
(Система автоматического конфигурирования для управления CPE
посредством протокола TR-069)
CONAX
(Платформа для предоставления услуги DVBC)

доступа.
(Платформа для предоставления услуги VoIP)
Система также должна предоставлять возможность быстрой настройки силами ИТ Блока
МРФ (без привлечения подрядчика) коннекторов к новым типам оборудования с использованием
открытых протоколов взаимодействия.
4 Требования к Системе
4.1 Назначение системы
Система предназначена для автоматизации процессов, необходимых для быстрого
развертывания услуг, предоставляемых абонентам МРФ. Под услугой понимается
определенный набор компонентов, необходимых для её предоставления. Это могут быть
сетевые элементы, серверы и сетевые сервисы, параметры тарификации и поддержки и
многое другое. Система активации отвечает за определение этого набора компонентов,
хранение параметров услуг, резервирование и выделение конкретных экземпляров
ресурсов для использования при предоставлении услуг, а также за настройку компонентов
участвующих в предоставлении услуг конкретному абоненту.
4.2 Цели создания Системы
Целью проекта является создание и внедрение Системы Активации Услуг для услуг
предоставляемых Организацией, которая обеспечивает автоматизацию процессов
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
подключения/отключения, активации/деактивации, модификации набора и характеристик
услуг.
В результате создания Системы должны быть достигнуты следующие цели:
 Унификация
интерфейса между
системой
управления
заказами
и
активируемыми с помощью Системы сетевым оборудованием, системами
предоставления услуг, и другими системами, участвующими в процессах
предоставлении услуг;
 Сквозная вендорно-независимая активация услуг;
 Повышение эффективности обработки заказов за счет существенного (на 60-80%)
 ускорения обработки заказов;
 Повышение эффективности обработки заказов за счет существенного (на 20-40%)
 Снижения ошибок конфигурации оборудования;
Система разрабатывается для управления предоставлением следующих услуг:
 Услуга доступа к сети Интернет
Дополнительно к данной услуге могут предоставляться услуги:
предоставляться сервис «Статический IP-адрес» с возможностью конфигурации
(смена mac адреса);
IP-Профи (настройка входящего и исходящего IP фильтра и обратной PTR-записи
силами абонента),
Услуги,
связанные
с
постоянным
или
краткосрочным
изменением
входящей/исходящей скорости Интернет («Догони до 100», «Турбнокнопка» …)
Услуги, связанные с изменением правил приоритезации пропуска трафика и
конфигурации SLA-профилей для порта абонента («Локальный драйв», VOIP,
IPTV),
Родительский контроль (предоставление доступа в Интернет по заданному
абонентом расписанию)
 Доступ к сети Интернет со статической маршрутизацией (в том числе, добавление и
настройка новых маршрутизируемых сетей)
 Виртуальная частная сеть (в том числе подключения «точка=точка» по L3/L2 VPN)
 IPTV (Цифровое телевидение);
Помимо базового сервиса абонентам доступен перечень дополнительных сервисов:
a. «Подключение дополнительного STB»;
b. Изменение пакета услуг.
Полный перечень сервисов будет определен в ТЗ.
 DVBC (Цифровое телевидение);
Помимо базового сервиса абонентам доступен перечень дополнительных сервисов:
a. «Подключение дополнительного STB»;
b. Изменение пакета услуг;
c. Изменение параметров услуги (подключенные пакеты каналов);
d. ТВ-информирование абонента;
e. Смена PIN кода STB устройства;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
f. «Pairing» STB устройства и карты условного доступа при комплектации;
g. Просмотр актуального состояния подписок на CONAX;
 Управление услугами внешних провайдеров (Антивирусы);
 Услуга «Видеонаблюдение» (камеры видеонаблюдения);
 SIP ОТА (Цифровая телефония).
Помимо базового сервиса телефонии абонентам доступен перечень дополнительных
сервисов (ДВО):
a. «Переадресация вызова» (безусловная, при занятости, при неответе):
1) безусловная – позволяет переадресовывать все входящие вызовы,
предназначенные для абонента услуги, на другой номер, назначаемый
абонентом;
2) при занятости – позволяет переадресовывать входящие вызовы,
предназначенные для абонента услуги, на другой назначенный абонентом
номер, в случае если терминал абонента находится в состоянии вызова
(занятости);
3) при неответе – позволяет переадресовывать входящие вызовы,
предназначенные для абонента услуги, на другой назначенный абонентом
номер, если абонент не отвечает на них в течение предварительно
заданного периода времени.
b. «Ограничение исходящей связи по коду-паролю» - позволяет абоненту
запрещать/разрешать любую исходящую телефонную связь путем набора
своего кода-пароля;
c. «Трассировка злонамеренного вызова»;
d. «Уведомление о поступлении нового вызова» - обеспечивает уведомление
абонента во время разговора о поступлении нового вызова, при этом абонента
может ответить на этот вызов путем установки первого соединения в
состояние “ожидания” и, после ответа на второй звонок, вернуться к
прерванному разговору
e. «Конференц-связь трех абонентов» - позволяет организовать речевую
конференцию с тремя участниками. Абонент, организующий речевую
конференцию, может временно исключать одного из участников или отделять
их – т.е. остается связь только с организатором конференции, возвращать
участников в конференцию.
 ТфОП ОТА (Телефонная сеть общего пользования)..
Полный перечень дополнительных сервисов определяется и согласуется на этапе
технического проектирования при обследовании МРФ или по заранее разосланным
анкетам.
4.3 Требования к производительности
Система должна обеспечивать обработку не менее 500 000 запросов в сутки.
В часы наибольшей нагрузки система должна обеспечивать обработку и не менее 50
000 запросов в час (14 запросов в секунду).
Для ТВ-информирования услуги DVBC система должна обеспечить нагрузку не
менее 200 000 сообщений в час.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
4.4 Требования к системе в целом (нефункциональные требования):
Для разработки Системы должно использоваться серийно производимое
оборудование и промышленное программное обеспечение.
Система должна удовлетворять следующим основным требованиям:
 система должна обеспечивать коэффициент готовности не хуже, чем 99,95%;
 иметь модульную архитектуру;
 предусматривать возможность интеграции с другими системами;
Система должна создаваться таким образом, чтобы обеспечить возможность
расширения по следующим направлениям:
 Расширение числа услуг, активация которых обеспечивается системой;
 Расширение числа видов Сетевых Элементов (СЭ), управляемых системой;
 Расширение общего числа СЭ, управляемых системой;
 Расширение производительности системы.
 Допустимый процент ошибок в обработке заявок (включая некорректное
состояние абонента на оборудовании) по вине системы не более 0,05% в
сутки.
Система должна допускать все перечисленные выше расширения без внесения
значительных изменений в архитектуру системы.
Система также должна предоставлять возможность быстрой настройки силами ИТ Блока
МРФ (без привлечения подрядчика) коннекторов к новым типам оборудования с использованием
открытых протоколов взаимодействия.
Система должны быть спроектирована и внедрена в централизованном варианте, с
физическим размещением в головном офисе МРФ и при этом обладать возможностью
обеспечения операционной деятельности всех филиалов МРФ.
К промышленной установке системы Исполнитель разворачивает тестовую
установку системы, полностью дублируя на ней логику и настройки промышленной
установки, проведя интеграция с тестовыми платформами.
4.4.1 Требования к бизнес-процессам, автоматизируемым Системой
Система должна обеспечить автоматизацию перечисленных ниже бизнес –
процессов, в части настройки и конфигурирования оборудования и систем предоставления
услуг:
 Процесс первичного подключения услуг;
 Процесс приостановление услуг;
 Процесс возобновление услуг;
 Процесс изменения параметров обслуживания;
 Процесс отключение услуг;
 Процесс подключения разовых услуг.
 Процессы подготовки продуктов Общества к распространению (pairing
комплектов DVBC, подготовка предактивированных комплектов)
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
4.4.2 Требования к структуре
Обобщенная функциональная архитектура системы приведена на 1. Система должна
состоять из следующих функциональных модулей:
 Ядро обработки сценариев активации. Данный модуль должен обеспечивать
обработку запросов на активацию в соответствии с настроенными сценариями;
 Графический интерфейс разработки сценариев активации. Данный компонент
должен обеспечивать визуальную разработку сценариев с возможностью указания
детальных параметров для каждого из элементарных действий;
 Подсистема взаимодействия с оборудованием. Данный модуль должен
обеспечивать управление взаимодействием с оборудования. Непосредственно
взаимодействие к каждым типом оборудования должно производиться с
использованием подключаемых модулей (плагинов);
 Инструменты
разработки. Данный модуль предоставляет инструменты
разработки и тестирования модулей взаимодействия с оборудованием и
системами предоставления услуг (плагинов);
 Интерфейсный
модуль.
Данный
модуль
обеспечивает
интерфейсы
взаимодействия с системами верхнего уровня (OSS/BSS) и другими внешними
информационными системами;
 Подсистема учета ресурсов. Данный модуль должен обеспечивать хранение
информации о ресурсах и услугах, которая не может быть получена из внешних
систем, а также обеспечивать хранение оперативной информации используемой в
процессах активации/деактивации;
 Инструмент настройки подсистемы учета ресурсов;
 Графический пользовательский интерфейс. Данный модуль предназначен для
администрирования и настройки системы, а также диагностики ее работы.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
OSS/BSS
Web интерфейс
пользователей
Интерфейсы к
оборудованию
Plug-in
Инструмент
разработки
модулей
взаимодействия с
оборудованием
Инструмент
разработки
сценариев
Подсистема взаимодействия с
оборудованием
Plug-in
Подсистема
учета
ресурсов
Plug-in
Инструмент
настройки
подсистемы
учета
ресурсов
Ядро обработки сценариев активации
Plug-in
Интерфейсы с OSS/
BSS
Остальные OSS/BSS
Система Активации
Сетевая инфраструктура и системы предоставления услуг

Рис. 1 «Функциональная архитектура Системы Активации Услуг»
4.4.3 Требования к надежности
Для обеспечения бесперебойной работы для создания Системы должен быть
использован аппаратный комплекс, реализованный по кластерной технологии,
обеспечивающей автоматизированное переключение узлов кластера в случае выхода
одного из них из строя.
Все системные файлы, конфигурации и прочие необходимые данные должны
периодически резервироваться.
Система должна обладать автоматическим механизмом резервного копирования и
восстановления.
Архитектура решения должна предусматривать возможность расширения решения до
катастрофоустойчивой конфигурации с географическим разделением дублируемых
элементов системы.
Архитектура Системы должна обеспечивать выполнение функций Системы в
круглосуточном режиме.
4.4.4 Требования к безопасности
Все внешние элементы технических средств Системы, находящиеся под
напряжением, должны иметь защиту от случайного прикосновения, а сами технические
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и
ПУЭ.
Система электропитания должна обеспечивать защитное отключение при перегрузках
и коротких замыканиях в цепях нагрузки, а также аварийное ручное отключение.
Общие требования пожарной безопасности должны соответствовать нормам на
бытовое электрооборудование. В случае возгорания не должно выделяться ядовитых газов
и дымов. После снятия электропитания должно быть допустимо применение любых
средств пожаротушения.
Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов
Системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и
электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук
строчной частоты и т.д.), не должны превышать действующих норм (СанПиН
2.2.2./2.4.1340-03 от 03.06.2003 г.).
Размещение оборудования на рабочих местах должно обеспечивать его безопасное
обслуживание и эксплуатацию.
4.4.5 Требования к эргономике и технической эстетике
Взаимодействие пользователей с прикладным программным обеспечением, входящим
в состав Системы, должно осуществляться посредством визуального графического
интерфейса (GUI). Интерфейс Системы должен быть понятным и удобным, и должен
обеспечивать быстрое отображение экранных форм. Навигационные элементы должны
быть выполнены в удобной для пользователя форме. Средства редактирования
информации должны удовлетворять принятым соглашениям в части использования
функциональных клавиш, режимов работы, поиска, использования оконной системы.
Ввод-вывод данных Системы, прием управляющих команд и отображение результатов их
исполнения должны выполняться в интерактивном режиме. Интерфейс должен
соответствовать современным эргономическим требованиям и обеспечивать удобный
доступ к основным функциям и операциям Системы.
Интерфейс должен быть рассчитан на преимущественное использование
манипулятора типа «мышь», то есть управление Системой должно осуществляться с
помощью набора экранных меню, кнопок, значков и т. П. элементов. Клавиатурный режим
ввода должен используется главным образом при заполнении и/или редактировании
текстовых и числовых полей экранных форм.
4.4.6 Требования к защите информации от несанкционированного доступа
Требования к разграничению прав доступа:
 Система должна обеспечивать доступ к Системе только авторизованных
пользователей;
 Права пользователей должны определяться согласно роли;
 Система должна обеспечивать защиту от несанкционированного доступа к
информации;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
 Права доступа должны назначаться как отдельному пользователю, так и группе
пользователей;
 В Системе должно быть разграничение прав доступа по функциям:
 Разграничение прав доступа по функциям должно быть следующее:
o Возможность просмотра результатов активации;
o Просмотр результатов активации, возможность просмотра очереди задач, а
так же возможность ручного запуска задач (и повторного перезапуска
задач);
o Возможность удаления задачи из очереди в зоне ответственности оператора.
4.4.7 Требования к способам и средствам связи для информационного обмена
между подсистемами
Информационное взаимодействие между подсистемами должно быть основано на
использовании программных интерфейсов соответствующих подсистем либо на
совместном использовании подсистемами одного и того же хранилища данных с
соответствующим разделением полномочий по чтению и записи.
4.4.7.1 Требования к характеристикам взаимосвязей Системы с внешними
информационными системами
С точки зрения интеграционной архитектуры, Система должна базироваться на
сервис-ориентированной модели (далее – SOA) и предоставлять интерфейсы, основанные
на открытых стандартах взаимодействия информационных систем посредством различного
рода сервисов. Данные интерфейсы должны обеспечивать выполнение функций Системы
посредством вызова соответствующих операций, определенных в интерфейсном
контракте. В зависимости от особенностей выполнения той или иной операции, в
контракте для нее однозначно должен быть определен один либо несколько из следующих
режимов вызова, определяемых контекстом конкретного использования:

Синхронный вызов операций. Используется для выполнения быстро выполняемых
операций.
 Асинхронный вызов операций. Используется для вызова сценариев активации,
выполнение которых требует некоторого, неопределенного количества времени.
Для обеспечения вышеприведенных вариантов вызова операций, Система должна
предоставлять следующие реализации своих интерфейсов:
 SOAP интерфейсы, обеспечивающие выполнение интерфейсных операций в режиме
реального времени.
 Файловый интерфейс групповых операций, позволяющий загружать списки
абонентов, объемом не менее 100 000 записей с указанием вызываемых операций и
изменяемых атрибутов/ услуг/состояния абонента.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
4.4.8 Требования к режимам функционирования Системы
Для Системы должны быть определены следующие режимы функционирования:
 нормальный режим функционирования;
 предаварийный режим функционирования;
 аварийный режим функционирования;
 регламентный режим функционирования.
Основным режимом функционирования Системы является нормальный режим.
Предаварийный режим функционирования Системы характеризуется отказом одного
или нескольких компонентов программного и/или технического обеспечения, не
приводящий к потере функций Системы.
Аварийный режим функционирования Системы характеризуется отказом одного или
нескольких компонентов программного и/или технического обеспечения и связан с
потерей части функций Системы.
Регламентный режим функционирования Системы используется для проведения в
Системе плановых работ. При работе в настоящем режиме допускаются перерывы в работе
Системы с предварительным информированием Пользователей.
В нормальном режиме функционирования Системы:
 программное обеспечение и технические средства пользователей и
администратора Системы обеспечивают возможность функционирования в
режиме 24x7;
 серверное программное обеспечение и технические средства обеспечивают
возможность
круглосуточного
функционирования,
с
перерывами
на
обслуживание, указанными в регламенте;
 исправно работает оборудование, составляющее комплекс технических средств;
 исправно функционирует системное, базовое и прикладное программное
обеспечение Системы.
 структура и конфигурация системы должны быть спроектированы и реализованы с
целью минимизации количественного состава обслуживающего персонала;
 структура системы должна предоставлять возможность управления всем доступным
функционалом системы как одному администратору, так и предоставлять
возможность разделения ответственности по администрированию между
несколькими администраторами;
 для администрирования системы к администратору не должны предъявляться
требования по знанию всех особенностей функционирования элементов, входящих в
состав администрируемых компонентов системы;
 аппаратно-программный комплекс системы не должен требовать круглосуточного
обслуживания и присутствия администраторов у интерфейса управления.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
4.4.9 Требования по диагностированию Системы
Система должна предоставлять инструменты диагностирования основных
программных процессов, трассировки и мониторинга их выполнения.
Система должна иметь функциональность самодиагностики и выдачи сообщений
внешним системам аварийных сообщений.
При возникновении аварийных ситуаций либо ошибок в программном обеспечении,
диагностические инструменты Системы должны позволять сохранять полный набор
информации, необходимой разработчику для идентификации проблемы (лог Системы,
текущее состояние памяти и файловой системы).
4.4.10 Требования к развитию и модернизации Системы
Система должна реализовывать возможность дальнейшей модернизации
программного обеспечения и комплекса технических средств.
Система должна поддерживать перенос данных (справочника Системы, сценариев
активации, шаблона команд и т.д.) при изменении версий программного обеспечения
компонентов Системы.
Система должна поддерживать совместимость компонентов при изменении версии
программного обеспечения одной или нескольких из подсистем.
Система должна предоставлять возможность увеличения производительности
посредством масштабирования.
Система должна поддерживать механизм масштабирования на основе разнесения
своих подсистем по разным аппаратным платформам, в том числе территориальнораспределенным.
4.5 Требования к функциям Системы
4.5.1 Сценарии использования
№
п/п
1
Название сценария
использования
Создание абонента
Активация оборудования
2
Деактивация оборудования
3
Удаление абонента
4
Приостановление услуги
5
Восстановление услуги
6
Удаление сервиса
7
Добавление сервиса
8
Описание сценария использования
Создание абонента в системах предоставления услуг и его
регистрация в системах учета ресурсов и сервисов
Конфигурирование оборудования предоставления доступа и
систем предоставления услуг в целях подключения услуги
абоненту
Конфигурирование оборудования и систем предоставления услуг
доступа в целях отключения услуги абоненту.
Удаление абонента в системах предоставления услуг и удаление
его регистрации в системах учета ресурсов и сервисов
Конфигурирование оборудования и систем предоставления услуг в
целях временного приостановления оказания услуги абоненту.
Конфигурирование оборудования и систем предоставления услуг в
целях восстановления оказания услуги абоненту.
Конфигурирование оборудования и систем предоставления услуг в
целях удаления сервиса из пакета сервисов, на которые подписан
абонент.
Конфигурирование оборудования и систем предоставления услуг в
целях добавления сервиса к пакету сервисов, на которые подписан
абонент.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
9
10
Предоставление интерфейсов
внешним системам для
получения фактического
состояния услуг на
оборудовании и сервисных
платформах
Выяснение причин
неисправности
Генерация отчетов о работе
системы
Администрирование системы
11
Обновление внутренних
справочников
12
13
14
15
16
Развертывание плагинов и
подключение модулей
Разработка сценариев и
плагинов
Разработка новых
интерфейсов с BSS\OSS
системами
Изменение параметров
подключенных услуг
Запросы на оборудование и сервисные платформы об актуальном
состоянии услуг для предоставления во внешние системы
(просмотр состояния подписок CONAX, проверка подписок
антивирусов, IPTV)
Поиск в системе причины сбоя при конфигурировании услуги
абонента на оборудовании и системах предоставления услуг.
Получение статистики о работе системы.
Произведение профилактических работ в системе для улучшения
или сохранения качества работы системы. Выполняется
администратором системы.
Ведение внутренних справочников в актуальном состоянии
(внутренней БД Inventory). Выполняется администратором
системы и с помощью автоматизированных механизмов
синхронизации справочников со смежными ИТ системами.
Развертывание вновь разработанных плагинов для изменения
функциональности Системы.
Разработка новых и модификация существующих сценариев
активации и плагинов к оборудованию
Разработка новых и модификация существующих интеграционных
интерфейсов с внешними OSS\BSS системами (как входящих, так
и исходящих)
Изменение профиля подключенных услуг на оборудовании
(например, изменение входящей, исходящей скорости ШПД,
изменение количество подключенных пакетов ТВ-каналов)
4.5.2 Общие требования к сценариям
При разработке сценариев необходимо учитывать следующие требования:
 Система должна обеспечить проверку достаточности и правильности
передаваемых из системы управления заказами данных;
 Система должна обеспечить получение недостающей информации из
внешних информационных систем;
 Система должна обеспечить защиту от выполнения нескольких сценариев
для одного абонента в единицу времени;
 Система должна обеспечить корректность обработки ошибочных ситуаций
при взаимодействии с внешними системами.

4.5.3 Требования к подсистеме конфигурирования оборудования
АСУУ должна обеспечивать конфигурирование оборудования по различным
протоколам: CLI (telnet/SSH), HTTP, SOAP, CWMP (TR-069).
Система должна поддерживать модели данных BroadbandForum, такие как TR-181i2,
TR-104 и TR-098 для конфигурации оборудования по протоколу CWMP.
АСУУ должна реализовывать возможности по автоконфигурированию устройства
при первоначальной загрузке. Необходимо идентифицировать и авторизовать устройство,
система должна автоматически конфигурировать это устройство в зависимости от типа
устройства и профиля абонента (определенного оператором).
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
Система должна поддерживать сценарии автоматической конфигурации и
первоначального подключения к сети CPE с использованием (в необходимой комбинации)
следующих данных:
 Device ID (OUI, класс продукта, серийный номер);
 уникального для автоконфигурации сочетания «логин» и «пароль»;
 сетевая информация, например полученной от DHCP Option 82.
 данные из внешних смежных систем
 использование любых доступных параметров (IP адрес, МАС-адрес, серийный
номер и т.д.), для проведения идентификации и авторизации.
Система должна содержать базу данных устройств, которые управляются этой
системой, и позволять оператору отображать через графический интерфейс все
необходимые устройства, которые находятся под управлением системой.
Система должна иметь возможность отслеживания статусов (состояния) управляемых
СЭ.
АСУУ должна уметь автоматически восстанавливать все параметры и настройки
абонентских устройств после выполнения «RESET» для восстановления работы услуг,
если данная функция реализуема на данном типе устройств.
Система должна иметь возможность конфигурировать все необходимые (и
допустимые на СЭ) параметры управляемых устройств, требуемые для предоставления
описанных в документе услуг, в том числе vendor-specific параметры.
Система должна предоставлять возможность выполнять операции на устройствах (при
наличии технической возможности):
 Добавление объекта конфигурации;
 Удаление объекта конфигурации;
 Перезагрузка устройства;
 Сброс устройства в заводские настройки;
 Модернизация ПО;
 Получение значения параметров (Get Parameter Values);
 Установка значения параметров (Set Parameter Values);
 Загрузка конфигурационного файла в устройство;
 Выгрузка конфигурационного файла из устройства;
 Проверка сетевой доступности устройства.
Система должна обладать гибким механизмом действий в ситуации возникновения
сбоев при выполнении массовых операций с абонентскими устройствами, а также при
обнаружении сбоев на устройстве в процессе активации или мониторинга.
Система должна автоматически восстанавливать набор услуг при замене
оборудования у абонента, а также, если устройство было возращено к заводским
настройкам, если существует техническая возможность.
Система должна позволять производить массовые операции над услугами.
Информация, которая должна быть доступна системе относительно абонентских
устройств (где применимо):
 информация об устройствах, подключенных к локальной сети (LAN) абонента;
 информация о сетевом (WAN) интерфейсе, например: длительность PPP
сессии;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
 информация о настройках беспроводной сети WLAN (включена/выключена,
имя сети (SSID), подключенные устройства и т.д.);
 локальный лог файл абонентского устройства;
 данные таблиц маршрутизации СРЕ;
 результат локального IP PING теста;
 статус локального DHCP сервера;
 статус LAN интерфейса (up/down/error/…);
 статус о трафике, посланном/принятом через LAN интерфейс;
 статус DSL интерфейса;
 статус о трафике, посланном/принятом через WAN интерфейс.
Система должна поддерживать механизмы по синтезу/подготовке конфигурационных
файлов для управляемого оборудования.
АСУУ должна предоставлять/иметь возможность интеграции с подсистемой DHCP.
4.5.4 Требования к сценариям взаимодействия с оборудованием
В данном разделе приведены требования к реализации сценариев, связанных со
взаимодействием с оборудованием Оператора связи или абонентским оборудованием
(CPE).
– Система должна обеспечивать активацию услуг согласно Error! Reference
source not found. в соответствии с бизнес процессами.
– В процессе активации услуг Система должна взаимодействовать с
оборудованием и системами предоставления услуг, указанных в Error!
Reference source not found.;
– Система должна взаимодействовать с оборудованием по протоколам
управления, используемым для конфигурирования оборудования оператора;
– Система
должна
обеспечивать
возможность
одновременного
конфигурирования множества оборудования;
– Система должна обеспечивать необходимое максимальное количество
соединений с конкретным оборудованием, а в случае необходимости соблюдать
очередность выполнения задач на этом оборудовании;
– Система должна обеспечивать возможность пакетной обработки большого
количества заявок
– Система
должна
поддерживать
механизм
транзакционности.
При
возникновении ошибки при выполнении команд Система должна вернуть
конфигурацию оборудования на момент до начала конфигурации;
– Система должна при необходимости поддерживать установленное соединение с
оборудованием (Connection Pool);
– Система должна обеспечивать добавление новых сервисов к уже
существующим только за счет добавления этих сервисов в справочник;
– Система должна обеспечивать целостность и непротиворечивость данных
сетевого оборудования;
4.5.5 Администрирование системы
– Система должна обеспечивать возможность оператору просматривать историю
выполненных команд на оборудовании;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
– Система
должна
предоставлять
интерфейс
разработчикам
для
изменения/создания новых сценариев активации и интеграционных
интерфейсов.
– Система должна предоставлять механизм ручного запуска сценариев по
заданному администратором списку
– Система должна предоставлять механизм для получения статических отчетов
по результатам своей работы;
– Система должна предоставлять механизм для обновления внутренних
справочников;
– Система должна обеспечивать графический пользовательский интерфейс для
выполнения следующих функций:
o Поиск в системе причины сбоя при конфигурировании услуги абонента
на оборудовании;
o Генерация отчетов о работе системы;
o Администрирование пользователей системы;
o Произведение профилактических работ в системе для улучшения или
сохранения качества работы системы;
o Ведение внутренних справочников в актуальном состоянии (внутренней
БД Inventory);
o Развертывание вновь разработанных плагинов для изменения
функциональности Системы;
4.5.6 Разработка сценариев и плагинов
Система должна предоставлять открытые и документированные инструменты для
разработки и модификации сценариев активации и плагинов
для интеграции с
оборудованием и внешними системами:
– Инструмент разработки сценариев активации должен предоставлять как
возможности создания сценариев с помощью графического пользовательского
интерфейса, так и в режиме редактирования исходных текстов сценария;
– Для реализации в сценариях активации сложной логики система должна
предоставлять возможность программирования на одном из широко
используемом языке программирования. (Например: Java.)
– Система должна предоставлять встроенный функционал планировщика,
позволяющего по заданному расписанию автоматически запускать сценарии
(например для управления услугами родительский контроль, турбокнопка)
– Разработанные сценарии и плагины должны иметь возможность переноса на
другую аппаратную или программную платформу. Как минимум должны
поддерживаться следующие платформы:
o Windows (x86, x64)
o Linux (x86, x64)
– Инструмент разработки плагинов к оборудованию должен предоставлять
готовые шаблоны для реализации специализированных плагинов;
– Систем должна предоставлять механизмы для отладки и тестирование
сценариев активации;
– Систем должна предоставлять механизмы для отладки и тестирование
плагинов;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
– Архитектура системы должна поддерживать жизненный цикл разработок и
настроек сценариев и плагинов (разделение на среды разработки, тестирования,
продуктивную, а также инструменты для переноса изменений между средами и
версионность)
Система должна предоставлять инструмент для разработки, отладки и тестирования
внешних интерфейсных модулей;
4.5.7 Требования к интеграции с внешними системами
Система должна содержать стандартный открытый интерфейс API для обеспечения
интеграции с внешними системами.
Система должна взаимодействовать со следующими информационными системами
(северный мост):
– АСР\CRM (PeterService (BIS), интеграционные шины SAP XI, IBM Web Sphere)
Прямое взаимодействие в части приема заявок на активацию услуг,
оповещение о результатах выполнения задачи и обратное - изменение
состояния абонента в АСР, запрос о состоянии лицевого счета абонента;
– СУЗ (Техноград Координатор Технологических Процессов (Workflow)) взаимодействие в части приема заявок на активацию услуг, изменения набора и
характеристик услуг, а также оповещение о результатах выполнения заявки;
– ЛТУ/NRI – взаимодействие в части получения, изменения данных по ресурсной
составляющей, бронирование, подключения.
– Файловый интерфейс групповых операций управления статусом абонента и
услуг (блокирование/разблокирование).
4.6 Требования к видам обеспечения
4.6.1 Программное обеспечение
Для реализации системы должны быть использованы уже имеющиеся следующие
отдельно лицензируемые программные продукты:
 HP OpenView Service Activator;
 СУБД Oracle 11g Enterprise Edition;
4.6.2 Техническое обеспечение
С учетом требуемых характеристик производительности и необходимости
облуживания Системой филиалов
ОАО Ростелеком Система должна иметь
высоконадежную (кластерную) архитектуру.
Характеристики компонентов ПАК, должны быть уточнены на этапе детального
проектирования системы.
4.7 Требования к документированию
В ходе выполнения работ по созданию Системы должны быть подготовлены
следующие документы:
– Техническое задание на создание Системы;
– Руководство по администрированию Системы;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
– Руководство пользователя Системы;
– Руководство по разработке сценариев активации, интерфейсных методов,
– Квалификационные требования к персоналу, эксплуатирующему систему;
– Программа и Методика приемо-сдаточных испытаний (ПСИ);
Все документы разрабатываются на русском языке.
Документы представляются в бумажном и электронном виде.
5 Порядок контроля и приемки Системы
5.1 Виды, состав, объем и методы испытаний Системы
Испытания Системы или ее частей представляют собой процесс проверки
выполнения заданных функций, определения и проверки соответствия требованиям
Документа количественных и (или) качественных характеристик, выявления и устранения
недостатков в Системе, в разработанной документации.
Испытаниям подвергаются:
– Подсистема активации;
– Система в целом.
На этапах адаптация программ целью является удостоверение факта
работоспособности оборудования в составе Системы или их частей в соответствии с
эксплуатационной документацией на это оборудование.
На этапах проведения предварительных испытаний, проведения опытной
эксплуатации, проведения приемочных испытаний целью испытаний является
удостоверение факта правильности функционирования в соответствии с Документом, как
отдельных частей Системы (подсистем), так и Системы в целом.
5.1.1 Виды испытаний
Должны быть проведены следующие виды испытаний Системы:
 предварительные испытания;
 нагрузочное тестирование;
 опытная эксплуатация;
 приемочные испытания.
5.1.1.1 Предварительные испытания
Предварительные испытания Системы должны проводиться для определения ее
работоспособности и решения вопроса о возможности приемки Системы в опытную
эксплуатацию.
Предварительные испытания должны выполняться после проведения подрядчиком
отладки и тестирования поставляемых программных и технических средств Системы и
представления им соответствующих документов об их готовности к испытаниям, а также
после ознакомления персонала Системы с эксплуатационной документацией.
Испытания могут быть автономными или комплексными.
Автономные испытания охватывают части Системы и проводятся по мере готовности
частей Системы к сдаче в опытную эксплуатацию.
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
Комплексные испытания должны проводиться для групп взаимосвязанных частей
Системы и для Системы в целом. Комплексные испытания должны включать в себя (но не
ограничиваться) сквозное функциональное тестирование процессов активации,
нагрузочные испытания.
5.1.1.2 Нагрузочное тестирование
Нагрузочное тестирование должно определить соответствие собственной
производительности системы, заявленным требованиям.
Тестирование должно проводиться путем загрузки системы заявками тестовых
абонентов по северным интерфейсам системы, эмулируя профиль нагрузки реальных
бизнес-процессов, включая следующие пункты:
– ТВ-информирования услуги DVBC
– Массовые блокировки по завершению биллинга и списанию абонентской
платы.
– Групповое добавление услуг/блокировок/изменения параметров абонентских
профилей на оборудовании.
– Стресс тестирование, с целью определения максимальной производительности
системы.
Для исключения влияния на результаты тестирования скорости отклика оборудования
тестирование должно проводиться в режиме эмуляции обмена данными с внешним
оборудованием по южным интерфейсам.
5.1.1.3 Опытная эксплуатация
Испытания на этапе опытной эксплуатации Системы должны проводиться с целью
определения фактических значений количественных и качественных характеристик
Системы и готовности персонала к работе в условиях ее функционирования,
корректировки (при необходимости) документации.
5.1.1.4 Приемочные испытания
Приемочные испытания Системы должны проводиться для определения соответствия
Системы Документу, действующим стандартам, для оценки качества опытной
эксплуатации и решения вопроса о возможности приемки Системы в промышленную
эксплуатацию.
5.1.1.5 Объем испытаний
В программе автономных испытаний указывают:
 перечень функций, подлежащих испытаниям;
 описание взаимосвязей объекта испытаний с другими частями Системы;
 условия, порядок и методы проведения испытаний и обработки результатов;
 контрольные примеры (тесты);
 критерии приемки частей по результатам испытаний.
В программе комплексных испытаний Системы или ее частей указывают:
 перечень объектов испытания;
 состав предъявляемой документации;
 описание проверяемых взаимосвязей между объектами испытаний;
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
 очередность испытаний частей Системы;
 порядок и методы испытаний, в том числе состав программных средств и
оборудования, необходимых для проведения испытаний.
Опытная эксплуатация Системы или их частей проводится на основании программы,
которая должна предусматривать:
 проверку технического состояния комплекса технических средств Системы;
 продолжительность опытной эксплуатации, достаточную для проверки
правильности функционирования Системы при выполнении каждой функции
Системы;
 выявление причин неисправностей комплекса технических средств и их
устранение;
 предварительное определение характеристик надежности Системы;
 определение качественных и количественных показателей выполнения функций;
 оценку качества выполненных работ;
 доработку программного обеспечения и эксплуатационной документации.
5.2 Общие требования к приемке работ по стадиям
Сдача-приёмка работ производится поэтапно, в соответствии с рабочей программой и
календарным планом.
По завершении работ Исполнитель должен представить на подписание Заказчику Акт
сдачи-приемки Системы в эксплуатацию с приложением оформленных в установленном
порядке протоколов испытаний Системы.
Оценка и приемка результатов работ должны осуществляться Заказчиком на
основании требований настоящего Технического задания и Дополнений к нему.
Приемку результатов законченной работы по созданию Системы осуществляет
Заказчик путем подписания Акта сдачи-приемки Системы в эксплуатацию полномочными
представителями сторон.
Все создаваемые в рамках настоящей работы программные изделия (за исключением
покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных
кодов, представляемых в электронной форме на стандартном машинном носителе
(например, на компакт-диске).
6 Условия гарантии
В течение 12 (двенадцати) месяцев после подписания Акта сдачи-приемки
результатов выполненных работ Исполнитель несёт гарантийные обязательства и
обеспечивает техническую поддержку результатов выполненных работ на следующих
условиях:
Тип поддержки: «Расширенный» (24x7). Данный уровень поддержки подразумевает
под собой следующее:
 Время приема запросов: стандартное рабочее время (кроме критических ситуаций);
 Срок реакции на запрос: 4 часа;
 Работы по решению проблемы ведутся в стандартное рабочее время (кроме
критических ситуаций);
Разработка Автоматизированной системы управления услугами (АСУУ)
Технические требования
 В случае возникновения критических ситуаций срок применения решения
(постоянного или временного, необходимого для возобновления работоспособности
системы) не должен превышать 4-х часов, по принятой в работу проблеме.
 Охватывает следующие виды работ:
 Решения проблем в работе системы;
 Оказание помощи в преодолении последствий сбоев и ошибок;
 Оказание помощи в установке обновлений системы;
 Периодический аудит системы;
В течение первого месяца после подписания Акта сдачи-приемки результатов
выполненных работ Исполнитель обеспечивает расширенные техническую поддержку на
следующих условиях:
 Консультирование по работе систем, стандартным процедурам эксплуатации
системы, решению аварийных ситуаций по телефону.
 Удаленное подключение к решению проблем и аварий на системе в течении
одного часа.