Система учета и обработки заявок отдела ОТО в ОДО "Мостра-групп"

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

Объектом исследования данной работы является проблема учета оборудования и обслуживания ИТ - заявок отдела ОТО ОДО «Мостра-групп», возможность автоматизации процесса сбора информации об оборудовании и работы с заявками на обслуживание.

Целью данного дипломного проекта является внедрение программного обеспечения для повышения эффективности и управляемости отдела ОТО ОДО «Мостра-групп».

Актуальность данного дипломного проекта заключается в том, что сегодня учет оборудования и заявок пользователей на обслуживание является одной из главных задач ИТ-отдела, т.к. большинство современных предприятий работают с применением персональных компьютеров, которые требуют постоянного технического обслуживания и модернизации.

Первоначально деятельность отдела была слабо формализована: группа технических специалистов без определенного регламента принимала заявки напрямую от пользователей и выполняла необходимые работы, а учет оборудования был организован очень слабо. По мере того как число пользователей увеличивалось, пришло понимание, что качественное обслуживание невозможно без опоры на некую формализованную логику работы -- на определенные правила, регламенты, автоматизацию процессов приема и обработки заявок, систему отслеживания запросов и централизованный учет оборудования.

Создание автоматизированной системы управления ИТ - инфраструктурой позволит формализовать учёт ИТ - заявок и оборудования, повысить прозрачность занятости сотрудников ИТ-отдела. Это даст возможность увеличить эффективность работы персонала, а так же создаст дополнительные возможности по сбору статистики и более эффективному управлению ИТ - отделом.

В соответствии с поставленной целью выдвигаются следующие задачи:

провести анализ работы ИТ - отдела предприятия;

организовать учет оборудования и комплектующих;

формализовать процесс прохождения заявок;

повысить прозрачность рабочего времени сотрудников ИТ-отдела;

сократить временные затраты на поиск проблемы;

повысить качество выполнения работ;

ввести контроль исполнения работ по обработке заявок;

создать базу заявок для отчётности.

1. Исследование предметной области

1.1 Автоматизированные системы учета и обработки заявок от пользователей

В последнее время все чаще в различных тематических изданиях уделяется внимание необходимости создания службы поддержки пользователей ИТ. Обычно при этом данную службу именуют одним из вариантов: "Call Center", "Help Desk", "Service Desk".

Основополагающие принципы организации службы.

В соответствии с жизненным циклом информационных систем, включающим периоды проектирования, внедрения, эксплуатации и развития, единственный период, когда система приносит реальную пользу организации - это период ее производственной эксплуатации. За весьма редкими исключениями, эксплуатация информационной системы предполагает использование ее сотрудниками организации, не входящими в службу ИТ - конечными пользователями информационной системы. При этом в большинстве случаев именно по повышению эффективности и качества работы этих конечных пользователей судят об эффективности и качестве информационной системы и качестве работы информационной службы. По сути, конечные пользователи являются заказчиками и потребителями информационно-технологических услуг (сервисов ИТ).

При рассмотрении отношений между конечными пользователями и службой ИТ была применена модель традиционных рыночных отношений. То есть имеется некоторая услуга, имеется поставщик соответствующей услуги и имеется покупатель соответствующей услуги. Поставщик и покупатель заключают некоторое соглашение, которое определяет условия предоставления услуги, ее качество и т.д.

Предметом договоренности в предлагаемой модели является некоторая услуга, предоставляемая сотрудникам компании департаментом информационных технологий, и которую в дальнейшем мы будем именовать "сервис ИТ".

Понятие "сервис ИТ" обычно употребляется в нескольких различных смыслах. С одной стороны - это услуга, которую служба ИТ предоставляет конечному пользователю. Например, доступ в интернет. Или -применение автоматизированной системы управления складом для выполнения учетных операций. Или - использованием аналитической системы для проведение маркетингового анализ информации о структуре продаж. С другой стороны, предоставление услуги связано с использованием целого ряда технологий и решений, а возможно - и иных сервисов. В этом смысле всякий сервис ИТ - это структурированный набор оборудования, программного обеспечения, технологий, других сервисов (иногда - более низкого уровня, но вовсе не обязательно). Например, предоставление доступа в интернет предполагает наличие доступа к внешнему провайдеру, каналов связи, корпоративной сети передачи данных, сервера доступа к корпоративной сети, персонального компьютера с установленным на нем системным программным обеспечением и браузером. Эта сторона сервиса ИТ не представляет и не должна представлять большой интерес для конечного пользователя. Но она очень важна для организации деятельности службы эксплуатации.

В рамках предлагаемой модели отношений "поставщик сервиса - потребитель сервиса" достижение успеха находится в существенной зависимости от действий обеих сторон. Это обуславливается высокой сложностью современных информационных систем, в том числе - клиентского оборудования и программного обеспечения (той части компонент сервиса ИТ, которая размещена непосредственно у конечного пользователя). Одной из острых проблем остается обучение пользователей работе с информационной системой. И поскольку система постоянно развивается - обучение должно происходить регулярно. Это позволит более качественно готовить сотрудников. Но обучение ни в коей мере не снизит собственно сложность системы. И в процессе работы с системой у пользователя все равно будут возникать различные вопросы и проблемы, связанные с сервисами ИТ.

Приняв решение о необходимости обратиться за поддержкой в службу ИТ, пользователь обычно оказывается в несколько неопределенной ситуации: кому именно задать вопрос? Здесь тоже возможны различные ситуации.

Спросить знакомого. Легче всего обратиться к человеку, которого знаешь. И он обязательно поможет, если конечно это в его силах. А как быть, если такого знакомого нет? Или в случае, когда у него недостаточно полномочий? Или если он занят выполнением важной работы?

Спросить любого сотрудника службы ИТ. Он, скорее всего посоветует: к кому именно следует обратиться по данному вопросу. Далее - спросить у рекомендованного. Возможно дальнейшее продолжение цепочки. Вероятность успешного результата невелика. Пользователю действовать таким способом неудобно. Но не только пользователю! Отсутствие ответственных за работу с пользователями сотрудников приводит к определенному хаосу в деятельности службы ИТ, а в итоге - к контрпродуктивному выяснению отношений.

Поэтому единственный вариант, когда любой пользователь точно знает к кому именно следует обращаться с вопросами, и при этом соответствующий представитель службы ИТ всегда готов выслушать обращение пользователя и предпринять необходимые шаги для решения поставленного вопроса - это создание в рамках департамента информационных технологий службы поддержки пользователей. В рамках которой должна существовать выделенная группа сотрудников, которые будут отвечать на запросы пользователей.

Но нельзя ограничиться только созданием такой группы. Чтобы запрос пользователя не оказался "повисшим в воздухе", а попал нужному специалисту и рассматривался в допустимые сроки, и созданная группа, и конечные пользователи должны работать в соответствии с определенными правилами. Дело в том, что с момента обращения пользователя в информационную службу за помощью, он в общем снимает с себя ответственность и может абсолютно ничего не делать, поскольку при разборе ситуации виноватой все равно окажется служба ИТ. Таким образом, уже сама служба становится заинтересованной в формализации поддержки пользователей, разграничении полномочий и упорядочении деятельности сотрудников при оказании помощи пользователям. Последовательность обработки обращений пользователей должна помочь сосредоточить силы сотрудников службы ИТ на наиболее важных и критичных событиях, происходящих в инфраструктуре ИТ, но вместе с тем не оставить без должного внимания и все остальные обращения пользователей. Происходит своеобразное разделение труда. Пользователи тоже участвуют в такого рода разделении труда, поскольку обращаются за помощью только к диспетчерам и не отвлекают своими вопросами остальных сотрудников департамента информационных технологий, давая им возможность работать более продуктивно.

Порядок оказания поддержки конечным пользователям должен быть четко формализован для всех участников процесса: пользователей, диспетчеров, специалистов информационной службы и внешних поставщиков сервисов.

С формально-организационной точки зрения перечисленные возможности и пути улучшения позволяют построить реально полезную для организации систему поддержки конечных пользователей. Они содержат рекомендации по изменению фундаментальных оценок роли департамента информационных технологий в деятельности организации и соответственно - в повышении его ответственности перед организацией и конечными пользователями как основными потребителями услуг ИТ. Для дальнейшего восприятия будет полезно определить более точно предмет деятельности службы поддержки.

1.2 Обращения пользователей

Предлагается следующий вариант классификации обращений пользователей в службу поддержки:

запрос обслуживания. Запрос, связанный с необходимостью обслуживания оборудования или иного компонента сервиса ИТ со стороны службы ИТ. Например, замена картриджа в лазерном принтере. Или переконфигурирование программного обеспечения на персональном компьютере пользователя;

запрос информации (консультации). Пользователю нужна дополнительная информация по сервису ИТ, порядку работы и тому подобное;

инцидент. Пользователь не может нормально работать: сервис ИТ недоступен или качество сервиса не удовлетворяет пользователя.

Такая классификация позволяет более эффективно строить дальнейшую обработку обращений. В зависимости от типа обращения оператор диспетчерской службы принимает решение о том, кто будет исполнителем данного обращения. Наиболее критичным для бизнеса типом обращения по понятным соображениям является инцидент. Обработка инцидента - основной процесс, выполняемый службой поддержки пользователей. Он включает в себя выполнение мероприятий по восстановлению работоспособности сервиса ИТ в кратчайшие сроки. В некоторых организациях приоритет данной задачи настолько выше остальных, что деятельность службы поддержки пользователей практически полностью сводят к устранению инцидентов (что не совсем верно).

1.3 Правила взаимодействия

Создание службы поддержки пользователей - это в первую очередь четкое определение: правил взаимодействия конечных пользователей со службой ИТ, правил работы сотрудников службы поддержки пользователей и правил взаимодействия сотрудников службы ИТ между собой. Правила должны содержать ответы на перечисленные ниже вопросы.

Взаимодействие конечных пользователей со службой ИТ:

каким образом конечный пользователь может обратиться за поддержкой;

какие запросы пользователя должны быть обработаны службой ИТ;

каким образом конечный пользователь может уточнить текущее состояние обработки своего запроса;

каким образом пользователь подтверждает закрытие своего запроса.

Работа сотрудников службы поддержки пользователей:

каким образом осуществляется учет обращений пользователей;

каким образом определяются приоритеты обработки обращений пользователей;

каким образом определяются исполнители, ответственные за обработку обращений пользователей;

каким образом специалист, ответственный за обработку обращения пользователя, осуществляет данную обработке;

каким образом сотрудники службы поддержки учитывают выполненные действия и отчитываются о проделанной работе.

Взаимодействие сотрудников службы ИТ между собой:

каким образом специалист назначается ответственным за обработку обращения пользователя

каким образом осуществляется контроль процесса обработки

каким образом может быть изменен ответственный за обработку обращения пользователя

На самом деле данные правила есть ни что иное, как формальные процедуры, реализующие отдельные бизнес-процессы департамента информационных технологий. Для их описания могут быть применены любые способы, применяемые для описания всяких бизнес-процессов и процедур: текстовое изложение, представление в виде диаграмм в стандартизованных нотациях, иное графическое представление… Поскольку процессы, как правило, достаточно сложные, рекомендуется применять при описании декомпозицию на модули и последовательную их детализацию.

Основным критерием при выборе варианта представления является удобство восприятия правил их исполнителями. С этих позиций, на наш взгляд, графическое представление имеет существенное преимущество перед простым текстовым изложением. Выбор строгой стандартизованной нотации позволит в дальнейшем эффективно анализировать процессы, и при необходимости - реорганизовывать. Но при этом стандартные нотации все же требуют определенной предварительно подготовки как "писателя", так и "читателей". Поэтому в большинстве организаций останавливаются на некотором упрощенном и интуитивно понятном способе отображения, добавляя к графическим данным необходимые текстовые пояснения. (рисунок 1.1)

Характеристика предприятия

Мостра-групп ? дистрибьюторско-логистическая компания, один из крупнейших импортеров продуктов питания в Республике Беларусь. Свою деятельность компания начала в 1992 году, в настоящее время входит в состав холдинга RTL-Holding, являющегося лидером дистрибьюторского и логистического бизнеса в РБ.

Департамент информационных технологий (ДИТ) насчитывает около 50 человек, включая программистов-разработчиков, программистов тех. поддержки, системных администраторов отдела технического обслуживания, 1С ? программистов, технических писателей, сотрудников отдела материально-технического обеспечения компаний.

Направления работы ДИТ:

разработка и техническая поддержка программного обеспечения;

техническая поддержка пользователей;

материально-техническое обеспечение.

Отдел технического обслуживания служит для обеспечения бесперебойной работы парка серверов, клиентских рабочих мест и приложений на предприятии.

Структуру и штатную численность отдела утверждает генеральный директор, исходя из объема задач, устанавливаемых отделу.

Руководство по выполнению работ в отделе осуществляет начальник отдела.

В состав отдела входят:

группа технической поддержки;

системный администратор.

Начальник отдела распределяет обязанности между сотрудниками техподдержки и системными администраторами. Планирует и организует работу с персоналом, в соответствии с общими целями развития компании.

Отдел ТО выполняет следующие функции:

осуществление мероприятий по обеспечению функционирования комплекса технических и программных средств компании;

изучение и анализ рынка информационных услуг с целью обеспечения производства и управления современными информационными технологиями;

проведение работ по оптимизации использования информационно - технических ресурсов;

проектирование структуры баз данных и механизмов доступа к ним;

разработка организационно-технических мероприятий по внедрению средств вычислительной техники, системного и прикладного программного обеспечения;

разработка и согласование с соответствующими подразделениями ИТ департамента схем внедрения конкретных информационных технологий;

организация приобретения программных средств, их проверка на соответствие предъявляемым к ним требованиям и передача в техническую эксплуатацию;

изучение и последующее внедрение нового перспективного системного программного обеспечения вычислительных средств, инструментальных и прикладных программных средств;

диагностика и устранение неполадок программного обеспечения;

своевременное рассмотрение и исполнение заявок, связанных с функционированием программного и аппаратного обеспечения;

консультирование и обучение пользователей программных средств по вопросам их изучения и внедрения;

разработка проектов инструкций, регламентов и стандартов по использованию программного и аппаратного обеспечения;

разработка, внедрение и организация контроля по обеспечению информационной безопасности;

подготовка заявок для закупки активного сетевого оборудования, серверов, средств резервного копирования и восстановления данных, средств защиты информации, средств контроля и управления сетевой инфраструктурой, периферийного оборудования, вычислительной техники и комплектующих, программного обеспечения, расходных материалов и запасных частей к устройствам печати и офисной технике;

установка, настройка, техническое сопровождение и обслуживание: серверов, активного сетевого оборудования, аппаратных и программных средств защиты информации, аппаратных и программных средств контроля и управления сетевой инфраструктурой, средств резервного копирования и восстановления данных, периферийного оборудования, программного обеспечения, офисной техники;

координация работ с поставщиками и производителями вычислительной и офисной техники по вопросам гарантийного обслуживания и ремонта;

координация работ с отделом разработки департамента -производителями программного обеспечения по вопросам приобретения, обновления и модификации;

анализ потребностей подразделений компании в дополнительных средствах вычислительной техники и обработки информации.

В результате исследования работы ИТ отдела были выявлены некоторые проблемы.

В настоящее время приём заявок осуществляется в устной форме (лично или по телефону). Данный подход в организации ИТ-обслуживания имеет ряд недостатков:

нет контроля за ходом выполнения заявки;

нет учета выполненных работ;

для пользователя нет информации о ходе выполнения его заявки;

не ведётся база знаний по решённым проблемам, что сказывается на эффективности работы сотрудников ИТ-отдела.

Также отсутствует централизованная система учета оборудования (все записи об учете ведутся либо только на бумаге, либо хранятся в электронном виде, но в разрозненных файлах). Такой метод учета имеет следующие недостатки:

нет возможности общего учета количества и состояния оборудования;

нет возможности учета оборудования по каким-либо характеристикам;

не ведется учет информации по произведенным ремонтам оборудования;

нет учета движения оборудования.

Постановка задачи

Назначение системы:

ведение учета рабочего времени сотрудников;

учет заявок от пользователей;

учет выполненных заявок;

формирование отчетов о проведенной работе сотрудниками.

Цели создания системы.

Основная цель разработки и внедрения системы учета отработанного времени сотрудниками, является повышение эффективности учета и обработки заявок ОТО на ОДО “Мостра-групп”, главными задачами которой являются:

разработка системы прав доступа к интерфейсу;

разработка алгоритмов и программных средств для учета и обработки заявок пользователей;

разработка алгоритмов и программных средств автоматизации учета отработанного времени.

Требования к структуре системы.

Ввод информации в систему обеспечивается:

операторным методом;

из СУБД MySql.

Информация выводится в виде:

экранных форм;

табличных отчетов.

При проектировании системы обеспечивается создание единых программного и пользовательского интерфейсов. Система должна функционировать в многопользовательском режиме.

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

Справочники, необходимы для работы системы. На подготовительном этапе работы системы учета материальных ценностей ее сотрудниками создаются справочники:

информация о пользователях;

информация об отделах;

информация об оборудовании;

информация о ПО;

информация о категориях заявок;

информация о подкатегориях заявок.

Входные и выходные формы.

Перечень входных форм:

ввод пользователя;

ввод отдела;

ввод оборудования;

ввод прикладного ПО;

ввод категории;

ввод заявки;

ввод решения.

Перечень выходных форм:

учет затраченного времени на решение заявок;

отчет по заявкам;

отчет по преобладающим заявкам;

отчет по списку оборудования на заказ;

отчет по вышедшему из строю оборудованию.

Основные требования к системе:

Для корректной работы программы необходим персональный компьютер, который бы удовлетворял следующим минимальным требованиям:

процессор Pentium 4;

оперативная память: 512 Mb;

SVGA 1024х768;

винчестер HDD 40 Gb;

устройство ввода и позиционирования Mouse (стандартная), 2 кнопки;

ОС: Windows XP/Vista/7.

На компьютере обязательно должен быть установлен Web-browser (Opera, Mazila или Internet Explorer).

Так же для работы понадобится локальный сервер Denver или Apache предназначенный для создания и отладки программы, СУБД MySQL, и любая программа по разработке PHP приложений (Adobe Dreamweaver, PHP editor и т.д.).

Вычислительная сеть:

В настоящий момент сеть компании ОДО "Мостра-групп" состоит из ЛВС и серверов (8 серверов в главном офисе)

Локальная вычислительная сеть главного офиса состоит из 760 рабочих мест и восьми серверов и 4 коммутаторных шкафов.

Порты коммутатора 10/100 обеспечивают выделенный канал для каждого соединения и поддерживают полнодуплексный режим работы.

Физически рабочие места подключены с помощью кабеля витой пары и соединены в общую локальную сеть при помощи коммутаторных шкафов.

В компании организована местная локальная сеть при помощи 4 коммутаторов с 40-ка портами с подключением в общую локальную сеть, все ПК пользователей подключены через сетевые розетки, которые скоммутированы с коммутаторами.

Спецификация активного оборудования коммутаторных шкафов:

Коммутатор 3Com SuperStack3 Switch 4226 40-port -4 шт.

Коммутатор Planet FNSW-2401, 80-port 10/100 - 8 шт.

Для связи между районными и региональными центрами коммутации использованы порты Channelized E1, которые позволяют оперировать с цифровыми каналами связи E0 SDH (64КБит/с) собирая их в произвольном порядке от 1 до 32 шт. При этом канал связи между региональным и районным центрами коммутации может быть дискретно расширен с 64Кбит/с до 2Мбит/с.

2. Проектирование системы

2.1 Функциональное проектирование системы учета и обработки заявок от пользователей

Функциональная модель системы разработана при помощи CASE- средства Bpwin.

BPwin является мощным средством моделирования и документирования бизнес - процессов. Этот продукт использует технологию моделирования IDEF0 (Inte-gration Definition for Function Modeling)

- наиболее распространенный стандарт, который принят для моделирования бизнес - процессов.

Компания LogicWorks, разработчик BPwin, сейчас входящий в Computer Associates, работает на рынке технологий моделирования уже более 10 лет, предлагая пользователям самые современные инструменты моделирования. При помощи инструментов СА/LogicWorks может быть автоматизирован весь цикл производства программного обеспечения, начиная с изучения и анализа бизнес-процессов предприятия и заканчивая генерацией структуры данных и объектов пользовательского интерфейса. Все средства разработки интегрированы друг с другом и позволяют создать основу для разработки следующего этапа.

Основными элементами диаграммы являются активности и дуги, которые изображают взаимосвязи и отношения активностей друг с другом. Дуги могут быть нескольких типов: вход, выход, управление и ресурсы. На каждой диаграмме обычно располагается от 3 до 6 активностей, это обусловлено тем, что такое количество активностей является оптимальным для восприятия сознанием. Модель BPwin представляет собой набор иерархически связанных и упорядоченных диаграмм, каждая из которых является конкретизацией (декомпозицией) активности предыдущего верхнего уровня. Каждая модель имеет одну диаграмму верхнего уровня, также называемая контекстная, которая содержит только одну активность, определяющую общую функцию моделируемого процесса и диаграммы декомпозиции предназначенные для детализации функций контекстной диаграммы и описывающие каждую подсистему и ее взаимодействие[1].

Кроме стандарта IDEF0, BPwin поддерживает также методологии моделирования DFD (data flow diagram) и IDEF3 (workflow). Методология DFD служит для описания потоков данных, которые возникают в результате деятельности компании. Методология IDEF3 служить для графического описания потока процессов (работ), взаимодействия процессов и объектов, которые изменяются этими процессами[6].

Контекстная диаграмма представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Контекстная диаграмма представлена на рисунке 2.1.

На контекстной диаграмме входной информацией является:

данные о пользователе;

данные о заявке.

Выходной информацией является:

отчет о выполненной заявке;

отчет о вышедшей из строя технике;

список техники к закупке.

Управлением является:

регламентирующие документы;

правила обраения в техническую поддержку;

перечень обслуживаемой техники и ПО.

К механизмам относится:

сотрудник тех. поддержки первого круга;

сотрудник тех. поддержки второго круга.

В результате декомпозиции блока «Учет и обработка заявок от пользователей» получилось 3 дочерние диаграммы:

регистрация заявки;

обработка заявки;

сбор статистики по заявкам;

Рисунок 2.2 - Декомпозиция контекстной диаграммы

В блоке «Регистрация заявки» входными данными являются «Данные о пользователе» и «Данные о заявке», механизмы - «Сотрудник тех. поддержки 1 круга», управление - «Правила обращения в техническую поддержку», «Регламентирующие документы» и выходные данные - «Назначенная заявка».

В блоке «Обработка заявки» входными данными являются «Назначенная заявка», механизмы - «Сотрудник тех. поддержки 1 круга» и «Сотрудник тех. поддержки 2 круга», управление - «Перечень обслуживаемой техники и ПО» и выходные данные - «Выполненная заявка», «Список техники к закупке», «Отчет о вышедшей из строя технике»,.

В блоке «Сбор статистики по заявкам» входными данными являются «Выполненная заявка» механизмы - «Сотрудник тех. поддержки 2 круга», управление - «Регламентирующие документы» и выходные данные - «Отчет о выполненных заявках».

Разработанные диаграмм могут быть детализированы. Например, на рисунке 2.3 представлена функциональная модель регистрации заявки.

В результате декомпозиции контекстной диаграммы «Регистрация заявки», рисунок 2.3, получилось 4 диаграммы декомпозиции:

добавление открытой заявки в БД;

проверка соответствия описания заявки её категории;

определение степени сложности заявки;

выбор свободного сотрудника технической поддержки.

В блоке «Добавление открытой заявки в БД» входными данными являются «Данные о пользователе» и «Данные о заявке», механизмы - «Сотрудник тех. поддержки 1 круга», управление - «Регламентирующие документы» и «Правила обращения в техническую поддержку» выходные данные - «Откытая заявка».

В блоке «Проверка соответствия описания заявки её категории» входными данными являются «Открытая заявка», механизмы - «Сотрудник тех. поддержки 1 круга», управление - «Регламентирующие документы» и «Правила обращения в техническую поддержку» и выходные данные - «Корректно составленная заявка».

В блоке «Определение степени сложности заявки» входными данными являются «Корректно составленная заявка», механизмы - «сотрудник тех. поддержки 1 круга», управление - «Регламентирующие документы» и выходные данные - «Проанализированная заявка».

В блоке «Выбор свободного сотрудника технической поддержки» входными данными являются «Проанализированная заявка», механизмы - «Сотрудник тех. поддрежки 1 круга», управление - «Регламентирущие документы» и выходные данные - «Назначенная заявка».

Моделирование представления системы учета и обработки заявок

Диаграмма вариант использования описывает последовательность действий, выполняемых системой, которая приводит к заметному результату, представляющему ценность для отдельного действующего лица.

На рисунке 2.4 представлена диаграмма вариант использования «учёт и обработка заявок от пользователей». На ней отображены последовательные действия сотрудника техподдержки, администратора и обычного пользователя.

Из диаграммы видно, что администратор может совершать операции по добавлению, редактированию и удалению записей в справочниках «Категории», «Отдел», «Подкатегории», «Пользователи», «Программное обеспечение», «Оборудование/комплектующие», «Решение», также может просмотреть отчеты.

Администратор как и сотрудник тех. поддержки может также создать заявку, выполнить заявку, удалить заявку, просмотреть все заявки по всем статусам, а также промотреть описание своей заявки и просмотреть свои заявки по всем статусам.

Сотрудник тех.поддержки кроме того, что перечислено выше, может добавить решение.

Пользователь же может создать заявку, просмотреть описание своей заявки и просмотреть свои заявки по всем статусам.

Таким образом, описанная диаграмма наиболее точно показывает компоненты разрабатываемой системы, необходимые для реализации требуемой пользователем функциональности.

Диаграмма классов _ центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.

Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.

На рисунке 2.5 представлена диаграмма классов.

2.2 Проектирование базы данных

Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование.

Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута ? поле этой таблицы.

Физическое проектирование данных осуществляется на основе логической модели. Результатом этого процесса является физическая модель, содержащая полную информацию, необходимую для генерации всех необходимых объектов в базе данных.

В результате анализа предметной области учета и обработки заявок от пользователей выявлены следующие сущности:

пользователь;

категория;

подкатегория;

решение;

отдел;

программное обеспечение;

оборудование;

заявка;

отчет.

В результате анализа полученных сущностей определяем связи между ними. Результат анализа представлен в таблице 2.1.

Таблица 2.1 ? Анализ полученных сущностей

Тип сущности	Тип связи	Тип сущности	Тип связи
	Подкатегория	Принадлежит	Категория

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Категория	Принадлежит	Заявка
Пользователь	Принадлежит	Заявка
Отдел	Принадлежит	Пользователь	1:1
Программное обеспечение	Принадлежит	Заявка
Оборудование	Принадлежит	Заявка
Решение	Принадлежит	Заявка	1:1
Заявка	Принадлежит	Отчет

После определения типов связей, выделим атрибуты сущностей. Выявленные атрибуты приведены в таблице 2.2.

Таблица 2.2 - Атрибуты сущностей и связей

Сущность	Атрибут
Отдел	Название отдела
Пользователь	ФИО пользователя
	Должность пользователя
	Телефон пользователя
	Имя пользователя
	Пароль пользователя
	Доступ пользователя
Категория	Название категории
Подкатегория	Название подкатегории
Программное обеспечение	Название программного обеспечения
	Комплект программного обеспечения
Оборудование	Наименование оборудования
	Состояние оборудования
	Количество оборудования
	Документ
Решение	Описание решения
Заявка	Тема заявки
	Описание заявки
	Статус заявки
	Специалист по заявке
	Автор заявки
	Время выполнения
Отчет	Название отчета
	Отчетный период
	Дата отчета

Для построения информационной модели системы лучше всего использовать ER-моделирование.

Логическая модель базы данных описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Логическая модель представлена на рисунке 2.6.

Физическая модель данных описывает данные средствами конкретной СУБД. Физическая модель данных реализована средствами именно реляционной СУБД, хотя, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД[1].

На рисунке 2.7 представлена инфологическая модель данных.

В результате проектирования получили набор таблиц баз данных.

Таблица Subcategory хранит информацию о подкатегории заявки, включая в свою очередь следующие поля: название подкатегории и порядковый индификатор подкатегории (таблица 2.3).

Таблица 2.3 - Структура таблицы Subcategory

Имя поля	Тип	Длина	Наименование
Id_subcategory	INT	10	Личный номер подкатегории
Name_sybcategory	TEXT	40	Название подкатегории

Таблица Category хранит информацию о категории заявок, а именно поля название категории, уникальный идентификатор категории и уникальный номер подкатегории (таблица 2.4).

Таблица 2.4 - Структура таблицы Category

Имя поля	Тип	Длина	Наименование
Id_category	INT	15	Идентификатор категории
Id_subcategory	INT	15	Идентификатор подкатегории
Name_category	TEXT	20	Название категории

Таблица Solutions хранит информацию о решениях и содержит поля описания решений и уникальные идентификаторы решений(таблица 2.5).

Таблица 2.5 - Структура таблицы Solutions

Имя поля	Тип	Длина	Наименование
Id_ Solutions	INT	15	Идентификатор решения
description_solutions	TEXT	20	Описание решения

Таблица Deportament хранит информацию об отделах, а именно такие поля как название отдела и уникальный идентификатор отдела(таблица 2.6).

Таблица 2.6 - Структура таблицы Deportament

Имя поля	Тип	Длина	Наименование
Id_deportament	INT	15	Идентификатор новости
name_ deportament	TEXT	20	Название отдела

Таблица User хранит информацию о пользователе, а именно такие поля как ФИО, телефон, должность, логин, пароль, доступ пользователя, а такаже уникальные идентификаторы пользователя и отдела (таблица 2.7).

Таблица 2.7 - Структура таблицы User

Имя поля	Тип	Длина	Наименование
Id_user	INT	15	Идентификатор пользователя
Id_deportament	INT	15	Идентификатор заявки
FIO_user	TEXT	15	ФИО пользователя
position_user	TEXT	15	Должность пользователя
phone_user	INT	20	Телефон пользователя
name_user	TEXT	15	Логин пользователя
pass_user	TEXT	15	Пароль пользователя
access_user	INT	20	Доступ пользователя

Таблица Software хранит информацию о программном обеспечении, а именно такие поля как название программного обеспечения, комплект программного обеспечения и уникальный идентификатор программного обеспечения (таблица 2.8).

учет заявка алгоритм программный

Таблица 2.8 - Структура таблицы Software

Имя поля	Тип	Длина	Наименование
Id_software	INT	15	Идентификатор программного обеспечения
name_software	TEXT	15	Наименование программного обеспечения
mode_software	TEXT	15	Комплект программного обеспечения

Таблица Hardware хранит информацию об оборудовании используемом сотрудниками компании, которая включает очередь следующие поля: наименование, состояние и количество оборудования, документ на оборудование и идентификатор оборудования (таблица 2.9).

Таблица 2.9 - Структура таблицы Hardware

Имя поля	Тип	Длина	Наименование
Id_hardware	INT	10	Личный номер оборудования
name_hardware	TEXT	40	Наименование оборудования
state_hardware	TEXT	40	Состояние оборудования
kolichestvo_hard	INT	30	Количество оборудования
Document	TEXT	40	Документ на оборудование

Таблица Request хранит информацию о заявках сделанных пользователями системы и включает следующие поля: тема, описание, статус, специалист, автор и время выполнения заявки,а также идентификационные номера заявки, категории, пользователя, отдела, программного обеспечения, оборудования, решения (таблица 2.10).

Таблица 2.10 - Структура таблицы Request

Имя поля	Тип	Длина	Наименование
1	2	3	4
Id_request	INT	10	Личный номер заявки
Id_category	INT	10	Личный номер категории
Id_subcategory	INT	10	Личный номер подкатегории
Id_user	INT	10	Личный номер пользователя
Id_deportament	INT	10	Личный номер отдела
Id_software	INT	10	Личный номер программного обеспечения
Id_hardware	INT	10	Личный номер оборудования
Id_solutions	INT	10	Личный номер решения
topic_request	TEXT	40	Тема заявки
description_request	TEXT	40	Описание заявки
status_request	TEXT	40	Статус заявки
technician_request	TEXT	40	Специалист по заявке
author_request	TEXT	40	Автор заявки
time_compl	INT	30	Время выполнения

Таблица Report хранит информацию об отчетах запрошенных администратором, которая включает следующие поля: наименование отчета, отчетный период, дату отчета, а также идентификационные ключи отчета, заявки, категории, подкатегории, пользователя, отдела, программного обеспечения, оборудования и решения(таблица 2.11).

Таблица 2.11 - Структура таблицы Report

Имя поля	Тип	Длина	Наименование
Id_report	INT	10	Личный номер заявки
Id_category	INT	10	Личный номер категории
Id_subcategory	INT	10	Личный номер подкатегории
Id_user	INT	10	Личный номер пользователя
Id_deportament	INT	10	Личный номер отдела
Id_software	INT	10	Личный номер программного обеспечения
Id_hardware	INT	10	Личный номер оборудования
Id_solutions	INT	10	Личный номер решения
Id_request	TEXT	40	Тема заявки
name_report	TEXT	40	Описание заявки
reporting_period	TEXT	40	Статус заявки
date_report	TEXT	40	Специалист по заявке

3. Разработка системы учета и обработки заявок пользователей

3.1 Алгоритм работы системы

Блок-схема - это графическое отображение процесса, которое четко показывает нам, как протекает процесс. Блок-схема показывает систематическую последовательность этапов выполнения работы и то, какие группы вовлечены в процесс.

Блоки А1 и Q1 - это начало и конец алгоритма, соответственно. Блок В1 служит для «Ввода данных пользователя». Блок B4 служит для условия перехода к определенным функциям, осуществление, выбор которых зависит от того, кто вошел в систему - администратор, пользователь или сотрудник тех. поддержки.

После осуществления входа переходим к блоку начала цикла D1 «Пока не завершена работа в модуле» для администратора, D6 для сотрудника тех. поддержки и E5 для пользователя. Далее следует логический блок «Выбор действий» D2 (D7 для сотрудника тех.поддержки и K5 для пользователя).

Зайдя под учетной записью с правами администратора выбираем действие, которое нужно выполнить из предложенных: блок H1 «Просмотр списка», I1 «Добавление записи в список», J1 «Редактирование данных записи», I2 «Просмотр выбранного отчета», K1 «Удаление выбранной записи», G4 «Просмотр списка всех заявок по всем статусам», H4 «Просмотр всех своих заявок по всем статусам», I4 «Создать заявку», J4 «Редактировать заявку», K4 «Удалить заявку».

Если пользовател вошел в систему под учетной записью сотрудника тех. поддержки выбираем действие, которое нужно выполнить из предложенных: блок L5 «Просмотр списка своих заявок», M5 «Создать заявку», N5 «Редактировать заявку», O5 «Удалить заявку», а так же F7 «Просмотр списка ПО», G8 «Просмотр списка всех заявок по всем статусам», H8 «Просмотр списка своих заявок по всем статусам», I8 «Создать заявку», J8 «Редактировать заявку», K8 «Удалить заявку»,

Если пользователь вошел в систему под учетной записью обычного пользователя выбираем действие, которое нужно выполнить из предложенных: блок L5 «Просмотр списка своих заявок по всем статусам», M5 «Создать заявку», N5 «Редактировать заявку», O5 «Удалить заявку».

Далее идет блок окончания цикла P1 (для упрощения восприятия окончание цикла у всех пользователей в одном и то же блоке) и окончание алгоритма блок Q1 «Конец».

Подробно алгоритм работы системы представлен на рисунке 3.1.

3.2 Программная реализация

В процессе создания программного продукта были реализованы различные функции и операции которые представлены в таблице 3.1 - описание основных файлов программы.

Таблица 3.1 - Описание основных файлов программы

Index.php	Форма авторизации
General.php	Главная страница
config.php	PHP-код для подключения к БД
Good.php	Обработчик ошибок
hardware.php	Страница работы со справочником оборудования
category.php	Страница работы со справочником категорий
Addrequest.php	Форма для добавления заявки
Otchets.php	Страница вывода отчетов
request.php	Страница вывода заявок
requestOpen.php	Страница детализации заявки
software.php	Страница работы со справочником ПО
solutions.php	Страница работы со справочником решений
subcategory.php	Страница работы со справочником подкатегорий
UsersAdm.php	Страница работы со справочником пользователей
style.css	CSS код для реализации дизайна всего сайта в целом

Система учета и обработки заявок построена на выполнении php скриптов.

Для вывода на экран данных из таблиц БД используются SQL запросы вида: select * from `category`

Для перехода по страницам используются кнопки. Некоторые из них не только пересылают пользоваетя на другую страницу, но и передают на вызываемую страницу данные. Часть листинга с кодом описывающим обработку нажатия на кнопку приведен ниже:

<input type='button' value = 'Все открытые заявки' onClick="location.href='request.php?param=6';">

Число записываемое в переменную глобального массива GET['param'] обработывается в открываемой странице через if условия, определяя выборку по какому статусу заявок выводить из БД данные. Для примера ниже приведен листинг кода обработки одного из значений переменной param.

<h2><a href="request.php?param=2"><strong>Ваши заявки в работе:</strong>

<?

$fio=$_SESSION['FIO_u'];

$query="SELECT * FROM `request` where Status_request='Обработка'&&(`Author_request`='$fio'||`Technician_request`='$fio')";

$result=mysql_query($query);

$num_results=mysql_num_rows($result);

echo $num_results;?>

</h2></a>

Создание новой заявки происходит через форму методом POST.

<FORM METHOD= "POST" ACTION= "Addrequest.php">

<CENTER><br> Тема заявки <input type='text' name='top_request' value=''/><br></CENTER>

<CENTER><br> Описание заявки <input type='text' name='desc_request' value=''/><br></CENTER>

<CENTER><br> Категория <select name='categ_req'></CENTER>

<?$query4="select * from `category`";

$result4=mysql_query($query4);

$num_results4=mysql_num_rows($result4);

for($i=0; $i<$num_results4; $i++)

{

$row4 = mysql_fetch_array($result4);

echo "<option value='".$row4['Name_category']."'> ".$row4['Name_category']." </OPTION>";

}?>

</select><br></CENTER>

<CENTER><br> Подкатегория <select name='subcateg_req'>

<?$query5="select * from `subcategory`";

$result5=mysql_query($query5);

$num_results5=mysql_num_rows($result5);

for($i=0; $i<$num_results5; $i++)

{

$row5 = mysql_fetch_array($result5);

echo "<option value='".$row5['Name_subcategory']."'>"

.$row5['Name_subcategory'].

"</OPTION>";

}?></select></CENTER>

<br>

<CENTER><br> <input type='submit' name='Add' value = 'Добавить'><br></form>

Данные записываются из формы в таблицу БД за счет выполнения следующего скрипта:

$top_req=$_POST['top_request'];

$desc_req=$_POST['desc_request'];

$ncat_req=$_POST['categ_req'];

$nsubcat_req=$_POST['subcateg_req'];

$auth_req=$_SESSION['FIO_u'];

$query9="INSERT INTO `request` (`Id_request`, `Topic_request`, `Description_request`, `Name_category`, `Name_subcategory`, `Status_request`,

`Technician_request`,`Author_request`,`Time_compl`)

VALUES (NULL,'$top_req','$desc_req',

'$ncat_req','$nsubcat_req','Открыта',

NULL,'$auth_req','NULL')";

mysql_query($query9);

Так в файле Index.php заключен php-скрипт, который отвечает за сравнение введенных пользователем логина и пароля симеющимися записями в БД и в случае совпадений выполняет переход на главную страницу системы с определенным для пользователя доступом. Срвнение введенных данных с данными в БД происходит за счет выолнения следующего программного кода:

$query="select * from user where Name_user='$user_name' && Pass_user='$user_pass'";

$result=mysql_query($query);

$num_results=mysql_num_rows($result);

if($num_results>0&&$num_results<2)

{

for($i=0; $i<$num_results; $i++)

{

$row = mysql_fetch_array($result);

$_SESSION['ID_U']=$row['Id_user'];

$_SESSION['FIO_u']=$row['FIO_user'];

$_SESSION['Otdel_u']=$row['Otdel_user'];

$_SESSION['Phone_u']=$row['Phone_user'];

$_SESSION['Position_u']=$row['Access_user'];

echo "<meta http-equiv='Refresh' content=\"0; url='General.php'\">";

}

}

Страницы работы со справочниками, такие как software.php, hardware.php, category.php, subcategory.php, solutions.php, UserAdm.php, построены на выполнении php скриптов совместно с sql запросами к БД. За счет чего данные из таблиц БД выводятся на экран перед пользователем, а также происходит запись и редактирование строк таблицы БД. Пример вывода на экран данных из таблицы Category приведен ниже.

$query3="select * from `category`";

$result3=mysql_query($query3);

$num_results3=mysql_num_rows($result3);

for($i=0; $i<$num_results3; $i++)

{

$row3 = mysql_fetch_array($result3);

if($_POST['id_c']==$row3['Id_category'])

{

echo '<tr><FORM METHOD= "POST" ACTION= "category.php">';

echo "<td><input type='text' name='Name_category' value='".$row3['Name_category']."'/></td>";

?><td><input type = 'submit' name='SAVEcategory' value='Сохранить'>

<input type = 'submit' name='DELETEcategory' value='Удалить'>

<input type = 'hidden' name = 'id_ca' value = <?=$row3['Id_category'];?> />

</td>

<?

echo '</form></tr>';

}

if($_POST['id_c']!=$row3['Id_category']) {

echo '<tr><FORM METHOD= "POST" ACTION= "category.php">';

echo "<td>",$row3['Name_category'],'</td>';

?><td><input type = 'submit' name='EDITcategory' value='Редактировать'>

<input type = 'submit' name='DELETEcategory' value='Удалить'>

<input type = 'hidden' name = 'id_c' value = <?=$row3['Id_category'];?> />

</td></form></tr>

<?}

}?></table>

В приведенном примере также внедрена форма для редактирования и добавления записи в данную таблицу БД. Данные выводятся в табличном виде, где первая строка будет являться формой для добавления записи в таблицу БД, рядом с каждой строкой будет выведено две кнопки "Редактировать" и "Удалить", которые соответственно либо откроют данную строку-запись таблицы для редактирования либо удалят выбранную пользователем запись из таблицы. Обработка данных действий происходит за счет следующего скрипта:

if(isset($_POST['SAVEhardware']))

{

$query="update hardware set Name_hardware = '".$_POST['Name_hardware']. "',

State_hardware = '".$_POST['State_hardware']. "',

Kolichestvo_hard = '".$_POST['Kolichestvo_hard']. "',

Document = '".$_POST['Document']. "'

where Id_hardware='".$_POST['id_ha']. "'";

mysql_query($query);

echo "<meta http-equiv='Refresh' content='0' >";

}

if(isset($_POST['DELETEhardware']))

{

$query="DELETE from `hardware` where Id_hardware='".$_POST['id_ha']. "'";

mysql_query($query);

}

Также в системе используются сессии для разграничения доступа между пользователями системы. В переменные сессии записывается уровень доступа и имя пользователя.

$_SESSION['ID_U']=$row['Id_user'];

$_SESSION['FIO_u']=$row['FIO_user'];

$_SESSION['Otdel_u']=$row['Otdel_user'];

$_SESSION['Phone_u']=$row['Phone_user'];

$_SESSION['Position_u']=$row['Access_user'];

Руководство пользователя

При входе в систему перед пользователем откроется страница авторизации представленная на рисунке 3.2, где пользователь должен ввести свой логин и пароль.

На стартовой странице расположена форма для авторизации. После ввода необходимых данных и нажатии кнопки «Войти». Если не были введены логин или пароль, то появится сообщение об ошибке входа (рисунок 3.3) и через несколько секунд пользователь вернется настраницу авторизации.

Ссылка «Авторизация» возвращает на главную страницу.

Если же были введены параметры входа, но с ошибкой, то появится сообщение об ошибке ввода параметров (рисунок 3.4).

Если пользователь авторизовался в системе, перед ним откроется главная страница с доступными, его уровню доступа, кнопками для переходов по страницам и сообщение приветствие (рисунок 3.5).

Если в систему вошел администратор, то слева ему будут доступны кнопки для перехода на страницы для редактирования справочников пользователей, категорий, подкатегорий, решений, устанавливаемого ПО и оборудования.

При нажатии на кнопку "Работа со списком пользователей" перед администратором откроется страница с таблицей данных по пользователям системы (рисунок 3.6).

На данной странице администратор может отредактировать данные о пользователе при нажатии на кнопку "Редактировать" напротив существующей записи либо удалить запись также нажав кнопку с названием "Удалить" напротив записи, при выполнении второго действия выбранная запись удалится из системы. Ниже прилагаются скрин выполнения нажатия на кнопку "Редактировать" (рисунок 3.7).

При нажатии на кнопку "Редактировать" поля таблицы станут доступны для ввода новой информации. Если далее администратор нажмет кнопку сохранить, введенные администратором данные заменят старые данные записи (рисунок 3.8).

Аналогичные операции администратор может производить и при переходе на страницы справочников категорий, подкатегорий, устанавливаемого комплекта ПО. Указанные страницы представлены на рисунках 3.9, 3.10, 3.11.

При нажатии на кнопку "Новая заявка" при любом уровне доступа откроется форма для добавления новой заявки. Она представлена на рисунке 3.12.

После заполнения полей, выбора категории и подкатегории и нажатия на кнопку "Добавить" перед пользователем появится сообщение о успешном добавлении заявки. Данная страница преставлена на рисунке 3.13.

При нажатии кнопки "Мои решенные заявки" перед любым пользоваетем системы откроется окно с создаными им заявками. Страница представлена на рисунке 3.14. По аналогии работают и остальные кнопки со статусами заявок, отражая в таблицах необходимые заявки.

Пользователь с доступом сотрудника тех. поддержки может может просмотреть открытую заявки кликнув мышью на любое поле строки заявки и перед ним откроется новое окно с детальным описанием заявки (рисунок 3.15)

Сотрудник тех. поддержки может назначить себя на выполнение, добавить решение и время выполнения заявки. При заполнении данных полей и нажатии кноки "Выполнить" заявка получит статус решена.

Пользователю с доступом администратора также доступна страница "Отчеты" представленная на рисунке 3.16.