66
конкретных выходных документов. Информационная модель изображена на рис.
2.2.
Основываясь на представленной информационной модели, представитель
подразделения создает заявку на печать в интерфейсе программы, указывает вид
печати и ее объем.
Менеджер при просмотре этой формы обнаруживает заявку, выполняет все
нужные действия для выполнения печати и при успешном исходе передает ей
статус «Закрыта».
ИС
Спр
Подразделения
Спр
Подразделения*
Спр Договора
Спр Договора*
Спр
Пользователи
Спр
Пользователи*
Спр Виды печати
Спр Виды
печати*
Т Заявки
Т Заявки*
Т Статус
Т Статус*
Сведения об
подразделени
ях
Регистрацп
одразделе
ния
Сведения о
видах печати
Учет видов
печати
Сведения о
договорах
Учет
договоров
Заявка
Учет
заявки
Сведения о
пользователя
х
Учет
пользовате
лей
Администратор
Список заявок
Список
заявок
Отчет по
заявкам за
период
Отчет по
заявкам за
период
Отчет по
заявкам по
сотрудникам
Отчет по
заявкам по
сотрудника
м
Отчет по
заявкам по
подразделени
ям
Отчет по
заявкам по
подраздел
ениям
Отчет по
заявкам по
типам печати
Отчет по
заявкам по
типам
печати
Администратор
Рис. 2.2 . Информационная модель
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
Входной информацией для проектируемой системы являются заявки
пользователей, сведения о подразделениях ГКУ ИАЦ, сведения о видах печати,
сведния о заключаемых и заключенных договорах. Эти данные поступают как в
цифровом, так и в печатном виде.
Данные из входных документов вносятся в систему путём ручного ввода
данных через веб-интерфейс.
67
В качестве данных о заключаемых договорах в систему вносятся
следующие данные;
Данные подразделения;
Наименование вида печати;
Срок договора;
Дата заключениея договора.
Сведения об инцидентах, а также сведения об отделах содержат только
наименования данных реквизитов.
Основным документом, вносимым в систему, является заявка
подразделения на печать документов.
Данный документ содержит следующие реквизиты:
наименование заявки;
описание заявки;
тип печати;
объем;
срок выполнения;
комментарий к заявке.
Для обеспечения работы системы предусмотрены справочники,
приведенные в таблице 2.3.
Таблица 2.3
Перечень используемых справочников
№
пп
название
справочника
ответственный за
ведение
средний
объём
справочника
в записях
среднюю
частоту
актуализации
средний объем
актуализации,
%
1.
Подразделен
ия
Администратор
45
1 раз в месяц
10
2.
Договора
Администратор
150
1 раз в год
10
3.
Пользовател
и
Администратор
250
1 раз в год
10
4.
Виды печати
Администратор
5
1 раз в год
10
68
2.2.3 Характеристика результатной информации
Основным результатным документом для разработанной системы является
список заявок пользователей, распределенный по следующим статусам:
новые;
распределенные;
в процессе;
на проверке;
закрытые;
удаленные.
Реквизиты данного документа следующие:
Подразделение;
Номер заявки по порядку в списке;
Регистрационный номер заявки;
Статус;
Тип;
Файл, присоединенный к заявке.
Дата последнего изменения статуса заявки;
ФИО пользователя, открывшего заявку;
Наименование заявки;
Описание;
Тип печати;
Комментарий.
Данные реквизиты являются общими для всех заявок. Для заявок,
перешедших в статус Распределена и дальше (кроме статуса Удалена)
предусмотрены также следующие реквизиты:
сведения об исполнителе, в том числе:
o ФИО исполнителя;
o должность исполнителя.
сведения о жизненном цикле заявки, в том числе дата и время
изменения каждого статуса.
69
Также в системе формируются следующие отчеты:
отчет по поступившим, обработанным и закрытым заявкам за
произвольный период;
отчет по заявкам, поданным определенным подразделением за
произвольный период;
отчет по заявкам по типам печати.
Кроме того, для удобства работы администратора формируются
следующие выходные документы:
список подразделений;
список договоров;
список типов печати.
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
В созданной системе есть 3 вида пользователей:
• Администратор системы – его роль выполняет сотрудник отдела
абонентского обслуживания. Главная обязанность такого пользователя –
рассылка заявок между сотрудниками отдела, основываясь на их загруженности
и опыте работы;
• Сотрудник, принимающий, выполняющий и закрывающий заявки;
• Пользователь системы, генерирующий заявки.
Подробное описание функции этих пользователей приведено на рисунках
2.3-2.4.
70
Функции
администратор
а
Служебные Общие
Управление
справочниками
Работа с
заявками
Добавление
записей
Удаление
записей
Просмотр
списков
Формировани
е новой
Удаление
заявок
Работа с
подразделения
ми
Добавление
Редактирован
ие
Учет
договоров
Рисунок 2.3 Дерево функций администратора
Исполнитель выполняет заявки:
Функции
исполнителя
Служебные Общие
Просмотр
справочников
Работа с
заявками
Пользователи
Просмотр по
статусам
Формирование
новой
Изменение
статуса заявки
Подразделения
Договора
Рис. 2.4 Дерево функций исполнителя
Исполнитель выполняет заявки и сообщает об этом, изменяя статус заявки.
71
Функции
пользователя
Служебные Общие
Просмотр
справочников
Работа с заявками
Пользователи
Просмотр по
статусам
Формирование
новой
Изменение
статуса заявки
Подразделения
Договора
Рис. 2.5 Дерево функций пользователя
Пользователь подает заявку, просматривает свои заявки по статусам.
На основании данных функций формируется сценарий диалога, схема
которого для каждого из пользователей представлена на рисунках 2.6- 2.7.
Главное
меню
Справочники
Типы
печати
Подразделе
ния
Заявки
Новые
Удаленные
Закрытые
Сформиров
ать
Сотрудники
Учесть
Удалить
Выход
Рис. 2.6 Сценарий диалога администратора
72
Меню исполнителя включает в себя работу с заявками, получение списка
сотрудников, просмотр конфигураций, а также кабинетов.
Главное меню
Подать заявку
Закрытые
Удаленные
Заявки
Архив заявок Выход
Рис. 2.7 Сценарий диалога пользователя
2.3.2 Характеристика базы данных
С учетом особенностей хранения данных и указанной организации их
хранения, приведем инфологическую модель данных, приведенную с
использованием стандартизированной методологии IDEF1X и средства Mysql
Workbench.
ER-модель разработанной базы данных представлена на рисунке 2.8.
Рисунок 2.8 ER-модель разработанной базы данных
73
Далее определим для каждой таблицы тип поля и формат содержащихся в
нем данных.
Таблица 2.4
Структура таблицы zav
№
Характер
информации
Характер
информации
таблицы
Тип
Примечание
1.
Код записи
idzav
int(10)
auto_increment
2.
Описание заявки
desczav
text
3.
Приоритет
priorzav
int(1)
4.
Актив
activzav
int(2)
5.
Категория
katzav
int(2)
6.
Ссылка на
прикрепленный
файл
filezav
text
7.
комментарий
commzav
text
8.
Код добавившего
пользователя
iduzav
int(3)
9.
Дата формирования
datezav
timestamp
10.
Наименование
namezav
varchar(255)
11.
Флаг удаления
deletz
int(1)
Таблица 2.5
Структура таблицы vidiprint
№
Характер
информации
Характер
информации
таблицы
Тип
Примечание
1.
Код записи
idtarif
int(11)
auto_increment
2.
Наименование вида
печати
nametarif
varchar(255)
3.
Количество
kilvokanal
int(12)
4.
Стоимость
prisepod
varchar(12)
5.
Примечание
abon
varchar(12)
6.
Флаг удаления
udaltarif
int(1)
Таблица 2.6
Структура таблицы status
№
Характер информации
Характер
информации
таблицы
Тип
Примечание
1.
Код записи
ids
int(10)
auto_increment
2.
Дата и время открытия
openz
varchar(45)
3.
Код пользователя
iduopen
int(2)
4.
Дата и время
распределения
rasp
varchar(45)
5.
Код пользователя
idrasp
int(2)
6.
Дата и время приема
proz
varchar(45)
7.
Код пользователя
idproz
int(2)
74
№
Характер информации
Характер
информации
таблицы
Тип
Примечание
8.
Дата и время проверки
test
varchar(45)
9.
Код пользователя
idtest
int(2)
10.
Дата и время закрытия
clos
varchar(45)
11.
Код пользователя
idclos
int(2)
12.
Флаг удаления
flag
int(1)
13.
Номер заявки
nomzav
int(3)
Таблица 2.7
Структура таблицы user
№
Характер информации
Характер
информации
таблицы
Тип
Примечание
1.
Код сотрудника
idu
int(11)
auto_increment
2.
ФИО сотрудника
nameuser
varchar(25)
3.
Дата регистрации
datereg
timestamp
4.
Логин для доступа в
систему
login
varchar(25)
5.
Пароль для доступа в
систему
password
varchar(25)
6.
Дата рождения
status
int(1)
7.
Флаг удаления
udaluser
int(1)
8.
Код отдела
iduserotd
int(1)
Таблица 2.8
Структура таблицы dogovor
№
Характер информации
Характер
информации
таблицы
Тип
Примечание
1.
Код договора
iddogovor
int(11)
auto_increment
2.
Код подразделения
idkldog
int(11)
3.
Код вида печати
idkltar
int(11)
4.
Дата заключения
договора
datedog
varchar(35)
5.
Срок
srok
varchar(24)
6.
Комментарий
commdog
text
7.
Дата закрытия
dateclosdog
varchar(45)
8.
Причина прекращения
cause
text
9.
Статус договора
statusdog
int(1)
Таблица 2.9
Структура таблицы Podrazd
№
Характер информации
Характер
информации
таблицы
Тип
Примечание
1.
Код подразделения
idKlient
int(11)
auto_increment
2.
ФИО
fam
varchar(255)
75
№
Характер информации
Характер
информации
таблицы
Тип
Примечание
3.
Имя и отчество
отвественного лица
name
varchar(100)
4.
Телефон
telefon
varchar(30)
5.
Адрес электронной
почты
email
varchar(150)
6.
Логин
login
varchar(25)
7.
Пароль
parol
varchar(25)
8.
Флаг удаления
udalkl
int(1)
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
Модули делятся на: пользовательские, административные, и системные.
Опишем основные конфигурационные модули.
Модуль авторизации необходим для проверки доступа пользователей к
системе. Так же, как и в ядре системы, в модуле реализована инициализация
механизма сессий и загрузка файла конфигурации (conf.php).
Затем происходит проверка, введены ли данные (логин и пароль).
Если такого не произошло, отображается форма для их ввода, в противном
случае осуществляется запрос к БД. В случае его успешного выполнения
(пользователь существует и его данные верны) происходит перенаправление на
главную страницу системы. В противном случае логин/пароль нужно будет ввести
еще раз.
Модуль «управления пользователями».
Этот модуль отнесен к административному типу и позволяет реализовывать
манипуляции с пользователями системы: создавать их, редактировать,
блокировать и активировать.
В момент создания нового пользователя, указывается его ФИО, логин,
пароль, адрес электронной почты, группы, к которым он будет принадлежать и
дата создания (заполняется автоматически).
В момент редактирования данных пользователя возможно изменение всех
данные, кроме пароля и времени создания, которые остаются неизменными. Если
утерян пароль, его восстановление происходит через интерфейс доступа к БД вне
зависимости от системы.