3Проектирование архитектуры системы автоматизации деятельности службы технической поддержки 3.1Описание сценариев использования системы
Использовать систему могут несколько типов пользователей:
клиент – пользователь, который задает вопросы;
инженер технической поддержки – пользователь, который имеет знания по разным технологиям и готовый отвечать на входящие вопросы клиентов;
администратор – пользователь, не участвующий в помощи клиенту напрямую, но следящий за сервисом; его возможности позволяют создавать новые аккаунты инженеров технической поддержки, а так же смотреть отчеты по задаваемым вопросам.
Опишем основные варианты использования.
Клиент способен создавать новые вопросы. Через некоторое время клиент может проверить состояние заданного вопроса и прочитать переписку с инженером. Если клиент столкнулся с проблемой второй раз, он всегда может посмотреть историю переписки всех своих предыдущих вопросов, что снизит нагрузку на инженеров технической поддержки.
Инженер технической поддержки следит за входящими вопросами. Когда к нему приходит новый вопрос или реактивируется старый, что случается, когда вопрос клиента остается не решенным даже после рекомендации инженера технической поддержки, он переходит к переписке с клиентом и отправляет сообщение с решением, опционально прикрепив файл. Инженер так же может зайти на страницу технологий и выбрать знакомые ему технологии из списка, по которым он способен консультировать клиентов.
Администратор же должен создавать аккаунты новым сотрудникам технической поддержки. Этот процесс схож с процессом регистрации клиента, но отличается тем, что новый аккаунт имеет другую роль в данной системе. Администратор, среди созданных им инженеров, может выбрать ответственного, которому дается статус «куратор». Куратором в данной системе называется инженер, которому будут приходить вопросы от клиентов, которым не получилось подобрать инженера технической поддержки или же вопрос не нуждался в категоризации. Он же этот вопрос должен решить – или сообщить клиенту, что продукт не поддерживает запрашиваемый сценарий или передать вопрос выше и решать его более комплексно. Администратор может смотреть отчеты, генерируемые сервисом, которые отображают актуальную картину по используемой продукции, а так же отображают информацию о производительности инженеров, что дает возможность сделать выводы о качестве труда рабочего персонала.
На рисунке 3.1 представлена диаграмма состояний системы автоматизации деятельности службы технической поддержки.
Рисунок 3.1 — Диаграмма состояний САДСТП
3.2Моделирование структуры системы 3.2.1Описание компонентов системы
Система состоит из следующих основных подсистем:
клиент – подсистема, работающая на ПЭВМ у пользователей, представляет собой графический интерфейс, а так же работает с веб-сервисом или через сеть интернет, или через внутреннюю корпоративную сеть;
веб-сервис – подсистема, которая слушает по сети обращения клиентов системы, следит за авторизацией и аутентификацией пользователей, выполняет все действия по обработке данных, а так же работает с базой данных;
база данных – подсистема, представляющая собой постоянное хранилище данных и состояний системы.
Устройство данных компонентов можно увидеть на рисунке 3.2.1.1.
Рисунок 3.2.1.1 - Устройство системы
Данные подсистемы включают в себя ряд компонентов:
клиент
набор представлений – компоненты, представляющие собой страницы или части страниц, состоящие только из графических элементов, обычно не имеющий логику;
набор поведений – компоненты, представляющие логику для соответствующих представлений; не имеют визуальной части; служат для разделения логической и визуальной частей;
модель – компонент, представляющий всю ключевую логику системы, на нем завязаны другие компоненты; конкретно для клиента, это является компонент, обеспечивающий связь с веб-сервисом;
Данный подход разделения компонентов называют MVC (Model-View-Component), у которого существует множество вариаций. То, как он выглядит в общем виде, показано на рисунке 3.2.1.2.
Рисунок 3.2.1.2 – Подход MVC в общем виде
веб-сервис
WCF – компонент, отвечающий на сетевые запросы от клиентов системы; каждому запросу соответствует функция с логикой обработки запроса; сам по себе сетевой веб-сервис строится по принципу RPC («remote procedure call» англ., по-русски «вызов удаленных процедур») – принцип клиент-серверного общения по сети, позволяющий компьютерным программам вызывать функции или процедуры в другом адресном пространстве на удаленных компьютерах;
логический блок – ключевой компонент в работе системы; именно он выполняет все важные функции, такие как: создание и обновление объектов в базе данных, агрегирование данных, выборка списка технологий для конкретного инженера технической поддержки, взятие имени пользователя по идентификатору, присвоение инженеру технической поддержки списка используемых им технологий, смена текущего куратора, генерация данных для отчетов;
блок доступа к данным – компонент, обеспечивающий связь с базой данных, он представляет собой набор классов объектов, с которыми работает и так называемый «контекст» для связи с базой данных; данный компонент использует подход ORM (англ. «Object-relational mapping», рус. «Объектно-реляционное отображение»), данная технология подходит для использования баз данных в объектно-ориентированных языках программирования, она связывает базу данных с концепцией ООП, создавая «виртуальную объектную базу данных»; просто надо сопоставить классы в языке программирования с соответствующими таблицами в базе данных.
база данных – для данной задачи рассматривается как единый компонент, состоящий из таблиц и хранимых данных.
Система должна устойчиво функционировать при бесперебойной работе ПЭВМ. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, система должна сохранять свою работоспособность после устранения сбоев и корректного перезапуска (за исключением случаев повреждения рабочих носителей информации с исполняемым программным кодом). Уровень надежности комплекса должен соответствовать технологии программирования, предусматривающей: автономное тестирование модулей (методов) программы; тестирование сопряжений модулей (методов) программы; комплексное тестирование программы.
3.2.2Описание диаграмм в системе
Теперь можно рассмотреть последовательность действий, таких как создание и конфигурация профиля инженера технической поддержки, как это показано на рисунке 3.2.2.1. Администратор, авторизовавшись в системе, может зайти на страницу создания нового инженера технической поддержки и, введя все требуемые параметры, создать аккаунт. Созданный инженер, зайдя первый раз, должен зайти на страницу технологий, выбрать «галочкой» те, что знакомы ему, и сохранить, что позволит отправлять к этому инженеру новые вопросы.
Рисунок 3.2.2.1 – Создание и конфигурация профиля пользователя инженера технической поддержки.
Рассмотрим последовательность обработки вопроса клиента, на примере рисунка 3.2.4. Вначале клиент должен обзавестись аккаунтов в сервисе. Это он делает своими руками – просто выбирает регистрацию в системе, заполняет требуемые поля и отправляет запрос на сервер, если введенные данные не конфликтуют с имеющейся информацией из базе данных (например, такое имя для входа уже используется), то сервис отвечает положительно и создает аккаунт. Теперь клиент сервиса может зайти на страницу создания нового вопроса, в которой должен ввести заголовок, тематику (или технологию), статус, сообщение и, если требуется, прикрепить небольшой файл (например, скриншот ошибки или файл с настройками) и сохранить сообщение. Веб-сервис, при запросе создания вопроса, попробует найти подходящего инженера технической поддержки для решения проблемы. Если такой не был найден, то вопрос будет виден куратору инженеров. Когда инженер, которому достался новый вопрос, зайдет в сервис с целью проверки актуальных вопросов, он увидит новый элемент в списке задач. Он ознакомится с задачей и, при необходимости, допишет сообщение с просьбой предоставить детали проблемы или недостающую информацию. Инженер ставит статус «закрыто», чтобы не видеть этот вопрос в списке отвеченных, сохраняет сообщение, и изменение должен увидеть клиент. Клиент, увидев новое сообщение в переписке, предоставит необходимую информацию, оставит вопрос со статусом «активен» и сохранит сообщение. Инженер найдет новое сообщение, и, ознакомившись с новой недостающей информацией, сможет найти решение, запишет его в переписку, выставит статус как «закрыт», сохранит и перейдет к решению следующих входящих вопросов.
Рисунок 3.2.2.1 – Диаграмма последовательности обработки вопроса клиента.
3.2.3Алгоритмы
В тот момент, когда веб-сервис пытается подобрать пришедшему новому вопросу соответствующего инженера, работает алгоритм, показанный на рисунке 3.2.3.1. Данный алгоритм принимает на вход «технологию», а так же читает из файла конфигурации, сколько дней надо анализировать для работы алгоритма (чем больше дней, тем точнее, но дольше время анализа). Затем выбираются инженеры технической поддержки по указанной технологии. Циклически начинаем искать среди найденных инженеров того, кто сейчас менее загружен. Расчет коэффициента наименьшей загруженности определяется путем нахождения среднего числа ответов в день (исключая дни, когда человек не выходил на работу; например, выходные не должны учитываться).
Рисунок 3.2.3.1 – Блок-схема алгоритма поиска подходящего инженера технической поддержки
Когда пользователь «Администратор» заходит в систему, он может запросить сгенерировать отчет о работе по входным данным системы. Один из таких отчетов является отчет о производительности труда инженеров технической поддержки. Алгоритм сбора данных для данного отчета представлен на рисунке 3.2.3.2.
Данный алгоритм циклически перебирает месяцы до текущего включительно, для каждого месяца он выбирает из базы данных, на сколько вопросов ответил каждый из инженеров. Алгоритм генерирует граф данных для отправки ответа за запрос клиенту приложения, чтобы он отобразил на экране данные в графическом или табличном виде.
Рисунок 3.2.3.2 – Блок-схема алгоритма агрегирования данных для генерации отчета об инженерах технической поддержки.
База данных имеет следующую модель:
вопросы (таблица «Thread») – это вопросы, возникающие у клиента в процессе использования приобретенного товара; они имеют такие атрибуты, как дата создания, статус, заголовок, идентификатор, так же хранит идентификаторы установленной технологии, инженера, клиента;
технологии (таблица «Technology») – хранит просто список технологий, используемых в текущей компании, служит для ассоциации с вопросом; атрибуты: наименование и идентификатор;
сообщения (таблица «ThreadItem») – список сообщений закрепленных за определенным вопросом, представляют собой историю переписки клиента с инженером технической поддержки; имеют атрибуты: текст, дата создания, идентификатор, хранит идентификаторы на вопрос, вложение и пользователя (который создал сообщение);
файловые вложения (таблица «Attachment») – хранит все файлы вложенные пользователями при отправке сообщения; имеют следующие атрибуты: наименование, содержимое, идентификатор;
пользователи (таблица «UserProfile») – это абстрактный тип в модели, потому что служит только для связи пользователи из системных таблиц, хранящих информацию о пользователях для авторизации, с клиентами и инженерами; таким образом имеет малое количество атрибутов: идентификатор системы авторизации и собственный идентификатор;
клиенты (таблица «CustomerProfile») – наследуются от «пользователей», используются для хранения информации о покупателях (заказчиках); имеет атрибуты: собственный идентификатор и идентификатор пользователя;
инженеры (таблица «SupporterProfile») – наследуются от пользователей; атрибуты: идентификатор, куратор, а так же имеет идентификатор пользователя;
умения (таблица «SupporterProfile_Technology») – служит только лишь для обеспечения связи «многие ко многим» между инженерами и технологиями, для хранения списка умений инженера; атрибуты: идентификатор технологии, идентификатор инженера.
Данное описание модели сопоставимо в с инфологической моделью. Инфологическая модель - модель наиболее высокого уровня абстракции. Инфологическая модель имеет синонимы «семантическая модель» и «концептуальная модель». Более наглядно с инфологической моделью САДСТП можно ознакомиться в рисунке 3.2.3.3.
Рисунок 3.2.3.3 – Инфологическая модель базы данных.
Серверная подсистема так же представляет собой веб-сервис, который состоит из набора методов для того, чтобы клиент системы имел доступ к данным.
Веб сервис имеет «простые» методы для выборки данных, а так же методы для вызова операции.
«Простые» методы для выборки данных:
GetAttachmentSet – получение вложений у сообщений для процесса выборки;
InsertAttachment – добавление вложения для сообщения;
UpdateAttachment – изменение вложения для сообщения;
DeleteAttachment – удаление сложений сообщения;
GetSupporterProfile_TechnologySet – получение связей между технологиями и пользователями для процесса выборки;
InsertSupporterProfile_Technology – добавление связи между технологиями и пользователями;
UpdateSupporterProfile_Technology – изменение связи между технологиями и пользователями;
DeleteSupporterProfile_Technology – удаление связи между технологиями и пользователями;
GetTechnologySet – получение технологий для процесса выборки;
InsertTechnology – добавление технологии;
UpdateTechnology – изменение технологии;
DeleteTechnology – удаление технологии;
GetThreadSet – получение вопросов для процесса выборки;
InsertThread – добавление вопроса (данный метод вызывает процедуру поиска свободного инженера для нового вопроса);
UpdateThread – изменение вопроса;
DeleteThread – удаление вопроса;
GetThreadItemSet – получение сообщений вопроса для процесса выборки;
InsertThreadItem – добавление сообщения в вопрос;
UpdateThreadItem – изменение сообщения;
DeleteThreadItem – удаление сообщения;
GetUserProfileSet – получение пользователей (как клиентов, так и инженеров) для процесса выборки;
GetCurrentUser – получить информацию о текущем пользователе;
GetQuestions – получение списка вопросов для процесса выборки;
Методы для вызова операции:
GetThreadItemProxies – получение списка сообщений в более читаемом формате для клиентской подсистемы по идентификатору вопроса;
GetFriendlyNameByProfileId – получение имени по идентификатору пользователя;
GetTechnologiesForSupporter – получение расширенного списка технологий по идентификатору инженера технической поддержки с указанием куратора;
AssignSupporterTechnologies – метод применения списка технологий на инженера технической поддержки;
GetSupportersSimple – отправка клиентской подсистеме «простого» списка инженеров технической поддежрки, только с именами и указанием куратора;
AssignCurator – метод, который может вызывать только администратор, служит для задания куратора среди инженеров;
GetTechnologiesReport – метод возвращает данные для генерации отчета по технологиям;
GetSupportReport – метод запускает алгоритм анализа работы инженеров технической поддержки и возвращает данные для постройки отчета по продуктивности работы инженеров.
|
