66
Средняя продолжительность пребывания клиента в системе:
????
????
????
????
Среднее число клиентов в очереди на обслуживание:
????
????
Средняя продолжительность пребывания клиента в очереди:
????
????
????
????
Модель позволила оценить качество работы сотрудников и всего отдела
информатизации в целом. Ключевой задачей при адаптации математического
аппарата в решении задачи станет подсчет оценки качества работы и проверка
правил и ограничений, накладываемых на систему влияниями реальных
факторов.
Стоит учитывать, что работа по математическому аппарату, описанному
выше, невозможна без использования статистических данных. При реальном
внедрении все табличные данные могут быть скорректированы после тестового
запуска на основании алгоритмов, которые будут описаны ниже.
Для начала нужно определить задачи, которые поступают специалисту
технической поддержки. Для каждой задачи определяем среднее время ее
выполнения, приоритетность и к какому специалисту нужно перенаправить
данный запрос. В основном в организации будут использоваться
непараллельные процессы, когда типы задач заранее распределены между
исполнителями и не могут передаваться от одного к другому в случае, если
данный специалист занят.
Так как специалисты второго уровня не могут решать чужие задачи, то
для каждого специалиста не составит труда определить список собственных
задач и определить время их решения, а также приоритетность этих задач. Также
оценку приоритетности должен дать сотрудник третьего уровня. Имея три
таблицы от специалистов второго уровня, система сможет определять задачи для
каждого специалиста, прогнозировать его занятость и время ожидания для
пользователя. Учитывая, что в системе недопустима потеря заявок, то будет
использоваться одноканальная СМО с ожиданиями и неограниченной очередью,
но нужно учитывать то, чтобы очередь не стремилась к бесконечности. Однако
67
при неограниченной очереди заявки должны сохраняться для выполнения
специалистом на следующий день. Для этого введем T – количество рабочих
часов в день специалиста второго уровня,
– время выполнения определенной
задачи, где n = 1, 2,3,…,n. У каждой задачи есть приоритет L, который является
числовым коэффициентом, позволяющим производить оценку задачи не только
по времени выполнения t
n
, но и по степени важности для организации. На
основе этих данных создана таблица оценки поступающих запросов.
Таблица № 7
Оценка поступающих запросов.
Специалист
Порядковый
номер задачи
Имя задачи
Среднее время
выполнения t
n
Приоритет L
Администратор БД
N
t
n
L
При составлении таблицы в нее вносятся запросы, которые можно
однозначно делегировать конкретному специалисту второго уровня, объективно
оценить среднее время выполнения на основании статистических данных и легко
оценить по уровню приоритетности для бизнес-процессов организации. Следует
исключить дублирование или двоякую трактовку одних и тех же запросов.
Корректно заполнив таблицу, можно приступить к написанию математических
правил распределения задач по специалистам второго уровня. Система должна
учитывать:
1) сколько задач у специалиста второго уровня находится в данный
момент;
2) длину очереди, состоящую из общего времени выполнения задач;
3) прогнозировать вероятность нахождения у специалиста второго
уровня определенного числа заявок в определенный промежуток времени;
4) следить за тем, чтобы очередь не стремилась к бесконечности и чтобы
общее время выполнения задач, поступивших специалисту второго уровня, не
превышало остатка времени рабочего дня;
5) организовывать изменения порядка очереди задач у специалиста на
основе приоритета задачи;
6) оценивать продуктивность специалиста по количеству выполненных
задач с применением собранной статистики;
68
7) автоматически сохранять или вносить изменения в статистические
данные, таблицу оценки поступающих запросов и менять вспомогательные
коэффициенты подсчетов;
8) автоматически подсчитывать коэффициенты качества работы отдела
информатизации.
Рассмотрим каждый пункт системы отдельно.
Пункт 1. Сколько задач у специалиста второго уровня находится в
данный момент. Пусть
- общее время задач в очереди специалиста второго
уровня.
Для прогнозирования вероятности количества задач у специалиста
второго уровня зададим коэффициент λ – количество заявок на единицу
времени, и коэффициент μ - плотность распределения заявок, где
. Для
подсчета вероятности занятости специалиста P
n
рассчитаем коэффициент
. Вероятность того, что в системе находится n заявок, рассчитаем по
формуле:
????
????
Для более точного подсчета вероятности количество заявок на единицу
времени посчитаем на основании количества заявок прошлого рабочего дня и
среднего количества заявок в данный день недели. Статистические данные
собраны в таблицу.
На основании этих данных мы можем прогнозировать количество заявок
у специалиста на определенном промежутке времени.
Пункт 2. Длина очереди, состоящей из общего времени выполнения
задач. Так как длину очереди можно измерять не только количеством
находящихся в ней задач, но и суммой времени выполнения всех этих задач, для
более качественной работы системы будем учитывать
задач в очереди. На
основании теории массового обслуживания можно рассчитать среднее число
находящихся в системе заявок на обслуживание, среднюю продолжительность
пребывания заявки в системе, среднее число заявок в очереди на обслуживание и
среднюю продолжительность пребывания заявки в очереди. Добавив к
измеряемым показателям еще и
задач в очереди и, учитывая реальное время
69
выполнения каждой задачи специалистом второго уровня, можно будет оценить
качество работы и продуктивность специалиста.
Пункт 3. Прогноз вероятности нахождения у специалиста второго уровня
определенного числа заявок в определенный промежуток времени. Учитывая
количество рабочих часов сотрудника в день, система должна следить за тем,
чтобы
не превышала Т или (T - T
раб
) ≤
, где T
раб
– количество часов,
отработанных сотрудником в данный день. В такой ситуации система должна
становиться СМО с ограниченной очередью, а также учитывать возможность
поступления задачи уровня L , который выше уровня последней задачи в
очереди и должен формироваться запрос на исключение неприоритетных задач и
включение приоритетных.
Пункт 4. Очередь не должна стремиться к бесконечности, общее время
выполнения задач, поступивших специалисту второго уровня, не должно
превышать остатка времени рабочего дня. Для предотвращения излишней
загруженности специалиста второго уровня и бесконечного роста заявок, введем
уровни для показателя P
n
, на основании которых возможны три варианта
реагирования системы:
1. P
f
, где f – заданное критическое количество заявок первого уровня и
P
n
< P
f
- система работает в нормальном режиме;
2. P
m
, где m - заданное критическое количество заявок первого уровня и
при котором P
f
< P
n
< P
m
– система старается предотвратить поступление
запросов низшего приоритета и прогнозирует их выполнение на следующий
рабочий день;
3. P
n
> P
m
- система превращается в СМО с ограниченной очередью,
временно останавливается прием задач низшего приоритета, а задачи высокого
приоритета добавляются вручную после обработки специалистом первого
уровня.
Пункт 5. Организация изменения порядка очереди задач у специалиста
на основе приоритета задачи. Единственным основанием для пересмотра
очередности задач в очереди специалиста второго уровня является коэффициент
приоритетности задач. Он работает по следующему принципу: в случае, если в
очереди находится какое угодно число задач L-уровня, за ними следуют задачи
уровня L-1,L-2 и так далее, поступающие задачи уровня L выполняются
70
системой сразу после задач L-уровня. Поступающие задачи уровня L всегда
ставятся в очередь после всех задач уровня L+1, L+2 и так далее, но перед
задачами уровня L-1, L-2 и прочих. Задачи одинакового уровня выполняются
последовательно.
Пункт 6. Оценка продуктивности специалиста по количеству
выполненных задач с применением собранной статистики. Так как система
сохраняет количество выполненных задач, приоритетность выполненных задач,
а также имеет доступ к оценкам среднего времени выполнения задач, она может
оценивать качество работы специалиста. Качество работы будем оценивать не по
среднему времени, которое применимо для подсчета вероятности загруженности
сотрудника, а по фактически затраченному времени на выполнение задач.
Простым методом измерения качества работы специалиста была бы оценка
своевременности обработки запросов пользователей. Ее можно рассчитать по
формуле
, где R — количество своевременно обработанных запросов, а N
— общее количество запросов, обработанных за некоторый период времени.
Однако применение такой формулы не позволяет оценивать количество
просроченных заявок (заявок, обработанных за время большее, чем t
n
). В самом
деле, если метрика рассчитывается по фактически исполненным запросам
(знаменатель N), то просроченные запросы исключаются из расчета данной
метрики, а у специалиста появляется время для обработки еще не просроченных
запросов.
Таким образом, просроченные запросы слабо влияют на показатель
качества работы сотрудника. Для решения данной проблемы коэффициент К
можно модифицировать. Пусть N помимо фактически решенных запросов, будет
включать в себя запросы, срок обработки которых на момент окончания
отчетного периода истек, а они так и не были решены. Тогда «зависшие»
запросы будут снижать значение метрики. Во-вторых, определение
не
учитывает, насколько был нарушен срок обработки запроса. Обычно
пользователю не все равно, был ли его запрос просрочен на 5 минут или на
неделю (имеется в виду рабочее время, а не новогодние праздники).
Для того чтобы учесть, на сколько нарушен срок, определим показатель
своевременности обработки следующим образом:
71
где
рейтинг обработки i-того запроса, равный 1, если i-тый запрос
обработан в срок, и 0 в случае, если он просрочен. А вес
определяется
формулой:
????
t
i
— фактическое время обработки запроса (рассчитанное по календарю
рабочего времени), T
n
— максимальное время обработки. Тогда чем сильнее
просрочен i-тый запрос, тем больше его вес W
i
, снижающий значение метрики
(поскольку t
i
> t
n
). Причем чем больше значение параметра n, тем быстрее
возрастает W
i
с увеличением срока обработки [23]. Таким образом, введение
веса W
i
, зависящего от длительности просрочки, стимулирует торопиться даже с
обработкой уже просроченных запросов. Дополнительное стимулирование
может производиться не только оценкой сотрудника, но и дополнительной
системой денежного стимулирования, рассчитываемой на основании
нормативного индекса K. Пусть премирование будет рассчитываться как оклад
сотрудника, умноженный на разницу К
реальное
– К
нормативное
в случае, если все
остальные показатели эффективности работы выше нормативных. Если любые
показатели ниже нормативных, премирование не происходит.
Пункт 7. Изменения в статистических данных, таблице оценки
поступающих запросов и вспомогательных коэффициентах подсчетов. Так как
коэффициент приоритетности может изменяться только человеком, то основным
изменяемым коэффициентом на основе статистических данных является t
n
для
каждой конкретной задачи. Среднее время для выполнения каждой задачи может
изменяться в связи со снижением/повышением продуктивности сотрудника,
изменением условий выполнения процесса и в связи с другими влияющими на
процесс факторами. Важно вносить изменения только при повторяющихся
факторах изменений. Это можно сделать подсчетом средних значений для t
n
72
каждой задачи на основе данных за указанный промежуток времени. Подсчет
будет производиться по формуле:
, где n – порядковый номер задачи. Однако во избежание
автоматических изменений t
n
больше, чем на 25% в случае, если t
> t
n
, то
вместо автоматической замены формируется запрос специалисту третьего
уровня с целью выяснения столь критичного изменения времени выполнения
задачи.
Пункт 8. Расчет коэффициентов качества работы отдела
информатизации. На основании всех введенных ранее коэффициентов можно
следить за качеством работы отдела информатизации не только со стороны
качества работы каждого сотрудника, но и со стороны качества работы отдела
для всей организации в целом. Основным критерием оценки качества должно
стать постепенное уменьшение средней продолжительности пребывания клиента
в системе, среднего числа клиентов в очереди на обслуживание и средней
продолжительности пребывания клиента в очереди. Снижение этих показателей
не только показывает ускорение работы отдела информатизации, но и позволяет
нарастить количество входящих запросов от организации.
Таким образом, разработанная математическая модель позволяет
сортировать поступающие в систему заявки по приоритетам и по специалистам,
ответственным за данный тип заявки, а также рассчитывать различные
статистические показатели, на основании которых можно судить о качестве
работы как отдельного сотрудника, так и всего отдела информатизации.
2.3.3. Характеристика базы данных
Информационно-логическая модель - модель предметной области,
которая определяет совокупность информационных объектов, отношений между
ними и их атрибутов, динамику изменений, происходящих в предметной
области, а также характер информационных потребностей пользователей,
которая не зависит от типа СУБД и ориентирована на человека.
Для описания инфологической модели может быть применена модель
«сущность-связь», которая подразделяет модели реального мира на «сущности»,
связанные друг с другом. Внутри моделируемой системы сущность имеет
73
уникальное наименование. Каждая сущность имеет несколько экземпляров,
каждый из которых имеет свой набор атрибутов. Этот набор должен однозначно
определять экземпляр среди прочих [14]. Такая модель называется
реляционной. В разрабатываемой системе используется именно реляционная
модель базы данных.
Реляционная модель данных — логическая модель данных, строгая
математическая теория, описывающая структурный аспект, аспект целостности
и аспект обработки данных в реляционных базах данных.
Структурный аспект — данные в базе данных представляют собой
набор отношений.
Аспект целостности — отношения (таблицы) отвечают
определенным условиям целостности. РМД поддерживает декларативные
ограничения целостности уровня домена (типа данных), уровня отношения и
уровня базы данных.
Аспект обработки (манипулирования) — РМД поддерживает
операторы манипулирования отношениями (реляционная алгебра, реляционное
исчисление).
Реляционная модель данных для систем управления базами данных была
разработана сотрудником исследовательской лаборатории компании IBMЭ. Ф.
Коддом. Э. Ф. Кодд, будучи математиком, разработал теорию реляционных баз
данных, свободную от недостатков прежних моделей. В 1970 г. он опубликовал
статью, посвященную краткому описанию новой модели.
Альтернативами реляционной модели являются иерархическая модель и
сетевая модель. Некоторые системы, использующие эти старые архитектуры, по-
прежнему используется до сих пор. Кроме того, можно упомянуть об объектной
модели данных, на которой строятся так называемые объектные системы
управления базами данных, хотя однозначного и общепринятого определения
такой модели нет.
В отличие от предшествующих моделей реляционная модель имеет
строгое математическое обоснование в виде теории множеств (реляционная
алгебра) и исчислении предикатов (реляционное исчисление).
Основой реляционной модели является отношение (relation). Отношение
содержит информацию об одной сущности (об одном классе объектов
74
предметной области) и представляет собой множество элементов, называемых
кортежами.
Для лучшего понимания реляционной модели данных следует отметить
три важных обстоятельства:
1) модель является логической, т.е. отношения являются логическими
(абстрактными), а не физическими (хранимыми) структурами;
2) для реляционных баз данных верен информационный принцип: все
информационное наполнение базы данных представлено одним и только одним
способом, а именно — явным заданием значений атрибутов в кортежах
отношений; в частности, нет никаких указателей (адресов), связывающих одно
значение с другим;
3) наличие реляционной алгебры позволяет реализовать декларативное
программирование и декларативное описаний ограничений целостности, в
дополнение к навигационному (процедурному) программированию и
процедурной проверке условий.
Наглядной формой представления отношения является таблица, в
которой значения атрибутов представлены столбцами, а кортежи – строками.
База данных представляет собой совокупность таких таблиц. Отметим, что при
реализации базы данных в СУБД столбцы таблицы называют полями, а строки –
записями [2].
Рис. 14. Схема таблиц в реляционной модели данных
75
Достоинства реляционной модели
Простота и доступность понимания конечным пользователем —
единственной информационной конструкцией является таблица.
При проектировании реляционной БД применяются строгие
правила, базирующие на математическом аппарате.
Полная независимость данных. При изменении структуры
реляционной базы данных изменения, которые требуется произвести в
прикладных программах, как правило, минимальны.
Манипулирование данными на уровне языка СУБД производится
ненавигационно, поэтому для построения запросов и написания прикладных
программ нет необходимости знания конкретной организации базы данных во
внешней памяти. Конечно, при исполнении запросов на физическом уровне
выполняется навигация по записям таблиц, однако эти действия производятся
процедурами самой СУБД.
Недостатки реляционной модели
По сравнению с иерархической и сетевой моделями реляционная
модель имеет более низкую скорость доступа и требует большего объема
внешней памяти. В настоящее время этот фактор не является критическим
вследствие многократно возросшего быстродействия компьютеров и такого же
роста объема дисковой памяти.
Часто в результате логического проектирования появляется очень
много таблиц, что затрудняет понимание структуры данных.
Далеко не всегда предметную область можно представить в виде
совокупности таблиц. Так, в системах автоматизации проектирования и
автоматизированной разработки программного обеспечения требуются гораздо
более сложные структуры данных.
Следующая ER-модель данных информационной системы,
представленная на рисунке 15, создана при помощи программного средства
MySQL Workbench.