Файл: Автоматизация обработки обращений в службу технической поддержки ФГУП РСВО.pdf

• • Периодические ошибки в подсчёте результатов деятельности.
  • Периодические ошибки в создании и анализе отчетов.
  • Большие временные затраты на поиск необходимых материалов.
  • Периодические ошибки при оказании технических услуг.

Для их решения потребуется построить диаграмму иерархию функций и контекстную диаграмму процесса функционирования отдела технической поддержки предприятия ФГУП РСВО .

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

Рисунок 9 - Иерархию функций управления и обработки данных

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

Схему информационных потоков представим на рисунке 10 в виде DFDдиаграммы.

Рисунок 10 - Контекстная диаграмма процесса функционирования отдела техподдержки.

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

Рисунок 11 - DFDдиаграмма потоков данных. Декомпозиция контекстной диаграммы

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

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

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

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

3.2 Характеристика базы данных

Проанализируем задачи работы. При более подробном рассмотрении поставленных задач, можно весьма ответственно утверждать, что такую задачу не решить без использования хранилища данных Любая программа, написанная на языке программирования высокого уровня, а у нас именно так, язык программирования С#, для решения такого рода задач, нужно где-то хранить данные, информацию, в нашем случае, информацию про заявки на оказание технической помощи. Кроме этого ее нужно обрабатывать. Решать такие задачи целесообразно и удобно используя БД. Для качественной работы в программе предусмотрено подключение к такой базе. Имеется в виду, что нужно создать базу данных. Под базой данных будем понимать такую базу данных, которая создана средствами других СУБД (напримерACCESS2007 или БД SQL на сервере), а не возможностями самого языка программирования (например хранить данные в массивах). Язык программирования используется только для связи с СУБД и обработки данных.

Кроме этого БД более эффективно поможет осуществить реализацию функционала программного комплекса.

Цели создания внешней БД:

• Структурированность необходимых данных;
• Наличие взаимосвязи данных (Связи в БД);
• Представление внешних данных в виде моделей данных для дальнейшего целенаправленного их использования;

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

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

Логическую модель БД представим на рисунке 12.

Рисунок 12 - Логическая модель БД

Далее на основании логической модели и при помощи СУБД строится таблицы физической (реляционной) БД. В нашем случае физическая модель БД состоит из 10 таблиц: Оператор БД, Мастер, Шаги, Акты, Расходы, Материалы, Склад, Отдел, Клиенты, Заявки.

Для проектирования базы данных по заданию "ИС Техподдержки» использовалось СУБД Microsoft SQL Server 2008 R2.

При помощи функционала данной СУБД и на основании поставленных требований была разработана БД "tex.mdf". В составе данной БД таблицы: Оператор БД, Мастер, Шаги, Акты, Расходы, Материалы, Склад, Отдел, Клиенты, Заявки.

Физическую модель БД представим на рисунке 13.

Рисунок 13 - физическая модель БД

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

В результате анализа были выделены 10 объектов, которые описывают дан­ную предметную область. Это:

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

− сущность “Материал”, атрибутами которой являются ID_ материала, название материала. Данная сущность включает в себя основные сведения о материалах склада. В качестве ключевого атрибута выбран ID_ материала. Данный атрибут является инверсным входом и он обязателен.

−сущность “Заявки” содержит следующие атрибуты: регистрационной номер заявки, ID_ оператора БД, ID_мастера, ID_клиента, дата подачи, причина, статус. Данная сущность включает в себя основные сведения о заявках на техпомощь отдела техподдержки. Ключевым атрибутом является ID_заявки. Данный атрибут является инверсным входом и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер клиента для связи с сущностью «Клиенты», регистрационной номер мастера для связи с сущностью «Мастера» и регистрационной номер оператора БД для связи с сущность «Операторы БД».

− сущность “Мастера”, атрибутами которой являются ID_ мастера, Фамилия Имя Отчество мастера и его статус. Данная сущность включает в себя основные сведения о мастерах отдела и их занятости. В качестве ключевого атрибута выбран ID_ мастера. Данный атрибут является инверсным входом и он обязателен.

−сущность “Оператор БД” в качестве атрибутов содержит регистрационный номер оператора, Фамилия Имя Отчество оператора. Данная сущность содержит информацию об операторах БД отдела. Ключевым атрибутом является ID_оператора. Данный атрибут является инверсным входом и он обязателен.

−сущность “Клиенты” в качестве атрибутов содержит регистрационный номер клиента, ID_ отдела, Фамилия Имя Отчество клиента. Данная сущность содержит информацию об клиентах отдела. Ключевым атрибутом является ID_клиента. Данный атрибут является инверсным входом и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер отдела для связи с сущностью «Отделы»

−сущность “Склад” в качестве атрибутов содержит регистрационный номер склада, ID_ материала, количества на складе. Данная сущность содержит информацию об наличии материалов на складе. Ключевым атрибутом является ID_склада. Данный атрибут является инверсным входом и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер материала для связи с сущностью «Материала»

−сущность “Расход” в качестве атрибутов содержит регистрационный номер расхода, ID_ материала, ID_ заявки, количества расхода, цена расходного материала. Данная сущность содержит информацию об расходах материалов на складе. Ключевым атрибутом является ID_расхода. Данный атрибут является инверсным входом и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер материала для связи с сущностью «Материала», регистрационной номер заявки для связи с сущностью «Заявки».

−сущность “Склад” в качестве атрибутов содержит регистрационный номер склада, ID_ материала, количества на складе. Данная сущность содержит информацию об наличии материалов на складе. Ключевым атрибутом является ID_склада. Данный атрибут является инверсным входом и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер материала для связи с сущностью «Материала»

−сущность “Акт” в качестве атрибутов содержит регистрационный номер акта, ID_ заявки, название акта, дата акта, цена акта. Данная сущность содержит информацию об созданных актах на выполненную работу. Ключевым атрибутом является ID_акта. Данный атрибут является инверсным входом, и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер заявки для связи с сущностью «Заявки»

−сущность “Шаги” в качестве атрибутов содержит регистрационный номер шага, ID_ заявки, суть шага, дата шага. Данная сущность содержит информацию об проделанных шагах по данной заявки. Ключевым атрибутом является ID_шага. Данный атрибут является инверсным входом, и он обязателен. В качестве внешнего ключа здесь выступают регистрационной номер заявки для связи с сущностью «Заявки»

Между объектами предметной области существуют связи, которые должны быть отражены в виде связей между объектами инфологической модели. Графи­чески связь обозначается линией, соединяющей связываемые объекты. Связь снабжается алфавитно-цифровым идентификатором. В каждом направлении связи можно выделить главный объект, от которого идет связь, и подчиненный.

Различают идентифицирующую связь и не идентифицирующую связь. При установлении не идентифицирующей связи дочерняя сущность остается незави­симой. Экземпляр сущности родителя может существовать безотносительно к ка­кому-либо экземпляру дочерней сущности.

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

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

Таблица 1 – Структура связей

На основании логического проектирования были созданы 10 таблиц, которые описаны в таблицах 2 - 11.

Описание атрибутов сущности «Заявки» представлено в таблице 2.