1.9Требования к функциям Системы Сценарии использования
№ п/п
|
Название сценария использования
|
Описание сценария использования
|
1
|
Создание абонента
|
Создание абонента в системах предоставления услуг и его регистрация в системах учета ресурсов и сервисов
|
2
|
Активация оборудования
|
Конфигурирование оборудования предоставления доступа и систем предоставления услуг в целях подключения услуги абоненту
|
3
|
Деактивация оборудования
|
Конфигурирование оборудования и систем предоставления услуг доступа в целях отключения услуги абоненту.
|
4
|
Удаление абонента
|
Удаление абонента в системах предоставления услуг и удаление его регистрации в системах учета ресурсов и сервисов
|
5
|
Приостановление услуги
|
Конфигурирование оборудования и систем предоставления услуг в целях временного приостановления оказания услуги абоненту.
|
6
|
Восстановление услуги
|
Конфигурирование оборудования и систем предоставления услуг в целях восстановления оказания услуги абоненту.
|
7
|
Удаление сервиса
|
Конфигурирование оборудования и систем предоставления услуг в целях удаления сервиса из пакета сервисов, на которые подписан абонент.
|
8
|
Добавление сервиса
|
Конфигурирование оборудования и систем предоставления услуг в целях добавления сервиса к пакету сервисов, на которые подписан абонент.
|
|
Предоставление интерфейсов внешним системам для получения фактического состояния услуг на оборудовании и сервисных платформах
|
Запросы на оборудование и сервисные платформы об актуальном состоянии услуг для предоставления во внешние системы (просмотр состояния подписок CONAX, проверка подписок антивирусов, IPTV)
|
9
|
Выяснение причин неисправности
|
Поиск в системе причины сбоя при конфигурировании услуги абонента на оборудовании и системах предоставления услуг.
|
10
|
Генерация отчетов о работе системы
|
Получение статистики о работе системы.
|
11
|
Администрирование системы
|
Произведение профилактических работ в системе для улучшения или сохранения качества работы системы. Выполняется администратором системы.
|
12
|
Обновление внутренних справочников
|
Ведение внутренних справочников в актуальном состоянии (внутренней БД Inventory). Выполняется администратором системы и с помощью автоматизированных механизмов синхронизации справочников со смежными ИТ системами.
|
13
|
Развертывание плагинов и подключение модулей
|
Развертывание вновь разработанных плагинов для изменения функциональности Системы.
|
14
|
Разработка сценариев и плагинов
|
Разработка новых и модификация существующих сценариев активации и плагинов к оборудованию
|
15
|
Разработка новых интерфейсов с BSS\OSS системами
|
Разработка новых и модификация существующих интеграционных интерфейсов с внешними OSS\BSS системами (как входящих, так и исходящих)
|
16
|
Изменение параметров подключенных услуг
|
Изменение профиля подключенных услуг на оборудовании (например, изменение входящей, исходящей скорости ШПД, изменение количество подключенных пакетов ТВ-каналов)
|
Общие требования к сценариям
При разработке сценариев необходимо учитывать следующие требования:
Система должна обеспечить проверку достаточности и правильности передаваемых из системы управления заказами данных;
Система должна обеспечить получение недостающей информации из внешних информационных систем;
Система должна обеспечить защиту от выполнения нескольких сценариев для одного абонента в единицу времени;
Система должна обеспечить корректность обработки ошибочных ситуаций при взаимодействии с внешними системами.
1.9.1Требования к подсистеме конфигурирования оборудования
АСУУ должна обеспечивать конфигурирование оборудования по различным протоколам: 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.
Требования к сценариям взаимодействия с оборудованием
В данном разделе приведены требования к реализации сценариев, связанных со взаимодействием с оборудованием Оператора связи или абонентским оборудованием (CPE).
Система должна обеспечивать активацию услуг согласно Error: Reference source not found в соответствии с бизнес процессами.
В процессе активации услуг Система должна взаимодействовать с оборудованием и системами предоставления услуг, указанных в Error: Reference source not found;
Система должна взаимодействовать с оборудованием по протоколам управления, используемым для конфигурирования оборудования оператора;
Система должна обеспечивать возможность одновременного конфигурирования множества оборудования;
Система должна обеспечивать необходимое максимальное количество соединений с конкретным оборудованием, а в случае необходимости соблюдать очередность выполнения задач на этом оборудовании;
Система должна обеспечивать возможность пакетной обработки большого количества заявок
Система должна поддерживать механизм транзакционности. При возникновении ошибки при выполнении команд Система должна вернуть конфигурацию оборудования на момент до начала конфигурации;
Система должна при необходимости поддерживать установленное соединение с оборудованием (Connection Pool);
Система должна обеспечивать добавление новых сервисов к уже существующим только за счет добавления этих сервисов в справочник;
Система должна обеспечивать целостность и непротиворечивость данных сетевого оборудования;
Администрирование системы
Система должна обеспечивать возможность оператору просматривать историю выполненных команд на оборудовании;
Система должна предоставлять интерфейс разработчикам для изменения/создания новых сценариев активации и интеграционных интерфейсов.
Система должна предоставлять механизм ручного запуска сценариев по заданному администратором списку
Система должна предоставлять механизм для получения статических отчетов по результатам своей работы;
Система должна предоставлять механизм для обновления внутренних справочников;
Система должна обеспечивать графический пользовательский интерфейс для выполнения следующих функций:
Поиск в системе причины сбоя при конфигурировании услуги абонента на оборудовании;
Генерация отчетов о работе системы;
Администрирование пользователей системы;
Произведение профилактических работ в системе для улучшения или сохранения качества работы системы;
Ведение внутренних справочников в актуальном состоянии (внутренней БД Inventory);
Развертывание вновь разработанных плагинов для изменения функциональности Системы;
Разработка сценариев и плагинов
Система должна предоставлять открытые и документированные инструменты для разработки и модификации сценариев активации и плагинов для интеграции с оборудованием и внешними системами:
Инструмент разработки сценариев активации должен предоставлять как возможности создания сценариев с помощью графического пользовательского интерфейса, так и в режиме редактирования исходных текстов сценария;
Для реализации в сценариях активации сложной логики система должна предоставлять возможность программирования на одном из широко используемом языке программирования. (Например: Java.)
Система должна предоставлять встроенный функционал планировщика, позволяющего по заданному расписанию автоматически запускать сценарии (например для управления услугами родительский контроль, турбокнопка)
Разработанные сценарии и плагины должны иметь возможность переноса на другую аппаратную или программную платформу. Как минимум должны поддерживаться следующие платформы:
Windows (x86, x64)
Linux (x86, x64)
Инструмент разработки плагинов к оборудованию должен предоставлять готовые шаблоны для реализации специализированных плагинов;
Систем должна предоставлять механизмы для отладки и тестирование сценариев активации;
Систем должна предоставлять механизмы для отладки и тестирование плагинов;
Архитектура системы должна поддерживать жизненный цикл разработок и настроек сценариев и плагинов (разделение на среды разработки, тестирования, продуктивную, а также инструменты для переноса изменений между средами и версионность)
Система должна предоставлять инструмент для разработки, отладки и тестирования внешних интерфейсных модулей;
Требования к интеграции с внешними системами
Система должна содержать стандартный открытый интерфейс API для обеспечения интеграции с внешними системами.
Система должна взаимодействовать со следующими информационными системами (северный мост):
АСР\CRM (PeterService (BIS), интеграционные шины SAP XI, IBM Web Sphere) Прямое взаимодействие в части приема заявок на активацию услуг, оповещение о результатах выполнения задачи и обратное - изменение состояния абонента в АСР, запрос о состоянии лицевого счета абонента;
СУЗ (Техноград Координатор Технологических Процессов (Workflow)) - взаимодействие в части приема заявок на активацию услуг, изменения набора и характеристик услуг, а также оповещение о результатах выполнения заявки;
ЛТУ/NRI – взаимодействие в части получения, изменения данных по ресурсной составляющей, бронирование, подключения.
Файловый интерфейс групповых операций управления статусом абонента и услуг (блокирование/разблокирование).
|
