Содержание

• Введение

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

  • 1.1 Общие сведения о системе и основания для разработки

  • 1.2 Назначение и цели создания автоматизированной системы технической поддержки

  • 1.3 Характеристика объекта автоматизации — службы технической поддержки телекоммуникационной компании

• 2 Требования к автоматизированной системе службы технической поддержки

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

  • 2.2 Требования к техническому, программному и информационному обеспечению системы

  • 2.3 Требования к надёжности, безопасности и качеству реализации функций

• 3 Состав и содержание работ по созданию системы

  • 3.1 Этапы и стадии разработки автоматизированной системы

  • 3.2 Порядок контроля, испытаний и приёмки системы в эксплуатацию

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

• Заключение

Приложения

Приложение А. Схема функциональной структуры АС ТП

Схема функциональной структуры автоматизированной системы представлена в виде диаграммы, отражающей состав подсистем и связи между ними. Система состоит из четырёх функциональных подсистем (управление заявками, учёт оборудования, аналитика и отчётность, интеграция) и единой базы данных PostgreSQL, к которой обращаются все подсистемы. Подсистема интеграции обеспечивает взаимодействие с внешними системами: биллингом, системой мониторинга (SNMP), CRM-системой и службой каталогов Active Directory. Пользователи получают доступ к функциям системы через веб-интерфейс, реализованный на базе React.

Описание элементов диаграммы:

Блок «Веб-интерфейс (React SPA)» — точка входа для всех пользователей. Связан с серверным приложением Django через REST API по протоколу HTTPS. Блок «Серверное приложение (Django)» — ядро системы, обрабатывающее бизнес-логику. Содержит модули: модуль управления заявками, модуль учёта оборудования, модуль аналитики, модуль интеграции. Блок «База данных (PostgreSQL)» — централизованное хранилище данных. Взаимодействие с сервером приложений через ORM (Object-Relational Mapping). Блок «Внешние системы» — биллинг, мониторинг, CRM, Active Directory. Связаны с системой через подсистему интеграции посредством REST API и SNMP.

Приложение Б. Концептуальная модель данных

Концептуальная модель данных АС ТП описывает основные сущности и связи между ними. Модель построена на основе методологии ER-диаграмм (Entity-Relationship).

Сущность «Абонент» содержит атрибуты: идентификатор (ID), фамилия, имя, отчество, лицевой счёт, адрес подключения, контактный телефон, электронная почта, тарифный план, дата подключения, статус (активен, заблокирован, отключён). Связь с сущностью «Заявка» — один ко многим (один абонент может иметь множество заявок).

Сущность «Заявка» содержит атрибуты: идентификатор (ID), номер заявки, дата создания, дата закрытия, категория, приоритет, статус (открыта, в работе, ожидает, закрыта), описание проблемы, результат решения, оценка абонента. Связь с сущностью «Сотрудник» — многие ко многим (заявка может передаваться между сотрудниками, один сотрудник обрабатывает множество заявок).

Сущность «Оборудование» содержит атрибуты: идентификатор, серийный номер, модель, тип (активное, пассивное), дата ввода в эксплуатацию, местоположение (ссылка на узел связи), статус (работает, неисправно, в резерве, списано), MAC-адрес, IP-адрес. Связь с сущностью «Узел связи» — многие к одному (на одном узле размещается множество единиц оборудования).

Сущность «Узел связи» содержит атрибуты: идентификатор, наименование, адрес, тип (центральный, распределительный, абонентский), координаты GPS, контактное лицо, количество портов (всего/занято/свободно). Связь с сущностью «Абонент» — один ко многим (к одному узлу подключено множество абонентов).

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

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

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

Экранная форма регистрации заявки содержит следующие элементы интерфейса. В верхней части — блок идентификации абонента: поле для ввода лицевого счёта или номера телефона с кнопкой «Найти». После идентификации отображается карточка абонента: ФИО, адрес, тарифный план, текущий баланс, статус подключения, список активного оборудования на узле связи абонента с индикацией текущего состояния (зелёный — норма, жёлтый — предупреждение, красный — авария).

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

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