Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

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

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

Задачами курсового проекта являются:

  • Описание предметной области;
  • Рассмотрение этапов проектирование и программирование;
  • Создание проекта ИС;
  • Тестирование;
  • Создание инструкции по эксплуатации и т.д.

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

1. Технико-экономическая характеристика предметной области и предприятия

1.1 Характеристика отдела и его деятельности

Проектирование АИС начнем с подробного рассмотрения и описания предметной области и определения основных объектов автоматизации.

В данном курсовом проекте в качестве объекта автоматизации, представляющего предметную область, является отдел технической помощи предприятия ФГУП РСВО».

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

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

Заявки регистрируются в любом количестве.

Исходными источниками информации для решения поставленной задачи являются:

- общая информация о структуре предприятия;

- описание деятельности предприятия и его отделов;

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

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

Таблица 1 - Характеристики предприятия

Характеристики

Значения показателя на определенную дату или период.

1

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

24ч

2

Время ремонта

24ч

3

Количество выпускаемой продукции

100шт

4

Затраты на ремонт оборудования

1000000 руб

5

Среднее количество рабочих чесов

6.7 часа

1.2 Организационная структура управления отдела

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

Рисунок 1 - Организационную структуру отдела технической поддержки

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

1.3 Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов

В качестве дополнения и на основании выше сказанного представим диаграммы действий, которая демонстрирует как происходило функционирование отдела технической поддержки до внедрения ИС. Смотрите рисунок 2.

Рисунок 2 - Диаграмма "Как было"

В дополнения представим функциональную диаграмму IDEF0. Смотрите рисунок 3.

Рисунок 3 - Декомпозиция 1 уровня диаграммы IDEF0

Проведем декомпозицию второго и третьего уровня. Смотрите рисунки 4,5, 6 и 7.

Рисунок 4 - Декомпозиция 2 уровня диаграммы IDEF0

Рисунок 5 - Декомпозиция 3 уровня диаграммы IDEF0

Рисунок 6 - Декомпозиция 3 уровня диаграммы IDEF0

Рисунок 7 - Декомпозиция 3 уровня диаграммы IDEF0

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

Цель:

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

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

Построенная модель ИС «"Отдел технической поддержки"» должна отражать существенные стороны деятельности отдела. ИС должна содержать компьютерное приложение, реализующее следующие процессы:

Программа должна обеспечивать возможность выполнения пе­речисленных ниже свойств:

  • Гибкость - настраивается на любую структуру, для широкого круга деятельности.
  • Безопасность - ограничение общего доступа к заранее определенным ресурсам БДД.
  • Целостность и доступность - поставки в базе дан­ных компании техподдержки должны быть представлены в общепринятых в орга­низации форматах защищенных от изменений.
  • Использование форм и шаблонов - позволит исполь­зовать типовые документы с возможностью изменений определён­ных полей.
  • Возможность поиска - фильтрация по БДД.

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

  • Добавление, удаление и обновление клиентов;
  • Добавление, удаление и обновление отделов компании;
  • Добавление, удаление и обновление заявок;
  • Добавление, удаление и обновление операторов БД;
  • Добавление, удаление и обновление мастеров;
  • Добавление, удаление и обновление шагов ремонта;
  • Добавление, удаление и обновление параметров акта по ремонту;
  • Добавление, удаление и обновление материалов;
  • Добавление, удаление и обновление материалов на складе;
  • Добавление, удаление и обновление расходов материалов на складе;
  • Поиск клиентов;
  • Поиск материалов;
  • Поиск материалов на складе;
  • Поиск мастеров;
  • Поиск операторов БД;
  • Поиск заказов по клиенту;
  • Поиск заказов по мастеру;
  • Поиск заказов по оператору;
  • Формирование этапов ремонта заявки;
  • Формирование акта выполненных работ;
  • Отчеты заявки по клиентам;
  • Отчеты заявки по операторам;
  • Отчеты заявки по мастерам;
  • Отчеты заявки по датам;
  • Отчеты заявки по статусу;
  • Отчет остатки по складу
  • Авторизация;
  • Вывод отчета в Exсel документ.

Ожидаемый результат :

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

2. Информационное обеспечение задачи

2.1 Информационная модель и её описание

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

Рисунок 8 - Выполнения заявки, основной бизнес процесс

2.2 Инструменты разработки

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

  • Язык программирования C#;
  • Платформа разработки Visio Studio 2012;
  • СУБД Access 2007.

Приведем обоснование выбора данных средств разработки. В современном мире широко используются следующие СУБД:

  • ACCESS;
  • MySQL;
  • Oracle;
  • Firebird;
  • PostgreSQL;
  • SQLite.

Рассмотрим Сервер Microsoft SQL. Производитель компания Microsoft. В текущий момент является одной из ведущих систем обработки данным в мире. Является современным программным продуктом. Постоянно обновляется и совершенствуется.

Основные плюсы такой СУБД:

  • Простота;
  • Удобство;
  • Простой и интуитивно понятный интерфейс;
  • Огромные функциональные возможности;
  • Компактность данных. Данные располагаются в таблицах, которые в сваю очередь занимают только один файл;
  • Огромное количество подсказок и мастеров, которые выполняют работа всю практически за вас;
  • Распространяемость;
  • Обновляемость;
  • Совместимость с ОС Windows;
  • Импорт и экспорт необходимых данных;
  • Наличие необходимых микрокоманд;
  • Встроенный SQL язык
  • Высокая степень защиты.

Недостатки:

  • Слабо развита возможность многопользовательского режима;
  • Слабо развита защита данных.

Рассмотрим СУБД Access 2007. Производитель компания Microsoft. В текущий момент является одной из ведущих систем обработки данным в мире. Является современным программным продуктом. Постоянно обновляется и совершенствуется. Входит в пакет программ Microsoft Office.

Основные плюсы такой СУБД:

  • Не сложна в использовании;
  • Удобство;
  • Простой и интуитивно понятный интерфейс;
  • Огромные функциональные возможности;
  • Компактность данных. Данные располагаются в таблицах, которые в сваю очередь занимают только один файл;
  • Огромное количество подсказок и мастеров, которые выполняют работа всю практически за вас;
  • Распространяемость;
  • Обновляемость;
  • Совместимость с ОС Windows;
  • Импорт и экспорт необходимых данных;
  • VBA
  • Наличие необходимых микрокоманд.

Недостатки:

  • Слабо развита возможность многопользовательского режима;
  • Слабо развита защита данных.

Проанализировав все плюсы и минусы, для выполнения данной работы была выбрана СУБД Microsoft Access 2007.

Анализ и выбор языка программирования.

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

С# - язык программирования высокого уровня. Объектно-ориентируемый язык. День рождения данного языка можно считать 1998 год.

Данный язык программирования был создан разработчиками компании Microsoft, как основной подход для программирования программных комплексов под ОС Windows. Имеет синтаксис подобный на другие языки высокого уровня с++ и java. Данный язык входит в основу таких платформ разработки приложений как WindowsForm, ASP. NetMVC, XAMARIN. Последнее кстати, многообещающая и быстро развивающаяся технология проектирования приложений для мобильных устройств.

Достоинства языка программирования:

  • Ярко выраженный объекта - ориентируемый подход;
  • Гибкость программного кода;
  • Переносимость программного кода;
  • Простата повторного использования готовых программных наработок;
  • Безопасность разработанного кода;
  • Унифицированная система типизации;

Недостатки:

  • Трудный и своеобразный синтаксис программного кода;
  • Мало новых, своих, идей;
  • Медленный, по сравнению с другими языками высокого уровня;
  • Не кросс - платформенный язык.

2.3 Техническое задание на проект

В рамках постановки задачи данной курсовой работы представим развернутое техническое задание на программный продукт:

Наименование программного изделия

Полное наименование программной разработки: «ИС Техподдержка», в дальнейшем именуемая как «Программа». Краткое название программы – «ИС Техподдержка».

Применения

Программа ИС«Техподдержка» предназначена для обработки и хранения данных необходимых для полного функционирования компании по оказанию услуг по ремонту и обслуживанию техники различной сложности. Может устанавливаться на всех ПК каждой фирмы РФ.

Назначение

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

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

Состав выполняемых функций

Программа должна обеспечивать возможность выполнения пе­речисленных ниже свойств:

  • Гибкость - настраивается на любую структуру, для широкого круга деятельности.
  • Безопасность - ограничение общего доступа к заранее определенным ресурсам БДД.
  • Целостность и доступность - поставки в базе дан­ных компании техподдержки должны быть представлены в общепринятых в орга­низации форматах защищенных от изменений.
  • Использование форм и шаблонов - позволит исполь­зовать типовые документы с возможностью изменений определён­ных полей.
  • Возможность поиска - фильтрация по БДД.
  • Возможность подключения независимых модулей для
  • Импорта данных из внешних источников данных в текущую БДД.

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

  • Добавление, удаление и обновление клиентов;
  • Добавление, удаление и обновление отделов компании;
  • Добавление, удаление и обновление заявок;
  • Добавление, удаление и обновление операторов БД;
  • Добавление, удаление и обновление мастеров;
  • Добавление, удаление и обновление шагов ремонта;
  • Добавление, удаление и обновление параметров акта по ремонту;
  • Добавление, удаление и обновление материалов;
  • Добавление, удаление и обновление материалов на складе;
  • Добавление, удаление и обновление расходов материалов на складе;
  • Поиск клиентов;
  • Поиск материалов;
  • Поиск материалов на складе;
  • Поиск мастеров;
  • Поиск операторов БД;
  • Поиск заказов по клиенту;
  • Поиск заказов по мастеру;
  • Поиск заказов по оператору;
  • Формирование этапов ремонта заявки;
  • Формирование акта выполненных работ;
  • Отчеты заявки по клиентам;
  • Отчеты заявки по операторам;
  • Отчеты заявки по мастерам;
  • Отчеты заявки по датам;
  • Отчеты заявки по статусу;
  • Отчет остатки по складу
  • Авторизация;
  • Вывод отчета в Exсel документ.

Ожидаемый результат:

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

Организация входных и выходных данных

В процессе работы программы входной информацией для программы должны являться: информация о клиентах, операторах, актах по работе, мастерах, материалах.

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

Временные характеристики, и размер занимаемой памяти

Время реакции программы на нажатие любой из клавиш и манипуляции мышью не должно превышать 0,25 с, в случае соответствия системных ресурсов требованию к составу и параметрам технических средств. Реакция на команды меню, кроме Открытия, Сохранения, Поиска не должна превышать 2 с. Реакция на команды Открытия, Сохранения, Поиска зависит от размера файла данных и настроек поиска.

Объем занимаемой оперативной памяти не должен превышать 8 Мбайт.

Требования к надежному функционированию

Программа должна нормально функционировать при бесперебойной работе ЭВМ. При возникновении сбоя в работе аппаратуры, восстановление нормальной работы программы должно производиться после: перезагрузки операционной системы; запуска исполняемого файла программы; повторного выполнения действий, потерянных до последнего сохранения информации в файл на магнитном диске.

Уровень надежности программы должен соответствовать технологии про­граммирования, предусматривающей: инспекцию исходных текстов программы; автономное тестирование модулей (методов) программы; тестирование сопря­жении модулей (методов) программы; комплексное тестирование программы

Контроль входной и выходной информации

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

Время восстановления после отказа

Время восстановления после отказа должно состоять из: времени переза­пуска пользователем операционной системы; времени запуска пользователем исполняемого файла программы; времени повторного ввода потерянных дан­ных.

Условия эксплуатации

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

Требования к составу и параметрам технических средств

Рекомендуемая конфигурация ПК:

  • Операционная система: Windows 7/8/8.1/10;
  • Процессор: Inte lCorei3/ AMDFX 4330 или мощнее;
  • Видеокарта: AMD Radeon 1Gb/Nvidia GeForce 640 1Gb или мощнее;
  • Оперативная память: 1Gb DDR3 RAM и более;
  • Жесткий диск: 100Mb свободного места;
  • Разрешение экрана: 1920X1080, 32 бит;
  • Звуковая карта: совместимая с DirectX 9.0

Необходимые программные компоненты:

Библиотека Microsoft. NET Framework 4.5

Требования к языкам программирования

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

  • Microsoft Visual Basic v5.0 и выше.
  • Borland Delphi v4.0 и выше.
  • Microsoft Visio Studio 2012 и выше

Выбор других языков нецелесообразен.

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

Для работы программы необходима операционная система WINDOWS 7 и более поздняя, драйвера мыши и принтера.

Требования к программной документации

Состав программной документации должен включать следующие доку­менты: Инструкцию по эксплуатации программного средства

Стадии и этапы разработки

Разработка программы должна выполняться по следующим этапам:

1) разработка, согласование и утверждение технического проекта про­граммы с пояснительной запиской - 5 недель;

2) разработка рабочего проекта программы с комплексным тестированием - 6 недель;

3) приемка-сдача с исправлением обнаруженных недостатков в программе и программной документации - 2 недели.

4)внедрение.

Виды испытаний

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

Испытания и тестирование программы должны проводиться в процессе создания программы самим разработчиком:

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

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

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

и проверка документации должна проводиться.

Испытания и тестирование программы должны проводиться после завершения создания программы заказчиком:

1. С использованием проверочных тестов, составляемых заказчиком заблаговременно.

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

3. Программное обеспечение задачи

3.1 Общие положения (дерево функций и сценарий диалога)

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

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

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

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

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

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

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_zaavki

int

PK

2

Id_admin

int

FK

3

Id_master

int

FK

4

Id_klient

int

FK

5

Pricina

Varchar()

20

6

Data

Varchar()

20

7

Status

Varchar()

20

Описание атрибутов сущности «Расход» представлено в таблице 3.

Таблица 3 – Описание атрибутов сущности «Расход»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_rachod

int

PK

2

ID_mat

int

FK

3

ID_zaavki

int

FK

4

Koll

Varchar()

20

5

Zena

Varchar()

20

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

Таблица 4 – Описание атрибутов сущности «Склад»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_sklad

int

PK

2

ID_mat

int

FK

3

Koll

Varchar()

20

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

Таблица 5 – Описание атрибутов сущности «Оператор»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_admin

int

PK

2

Name

Varchar()

20

3

Tel

Varchar()

20

4

Adres

Varchar()

20

Описание атрибутов сущности «Мастер» представлено в таблице 6.

Таблица 6 – Описание атрибутов сущности «Мастер»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_mastera

int

PK

2

Name

Varchar()

20

3

Tel

Varchar()

20

4

Adres

Varchar()

20

5

Status

Varchar()

20

Описание атрибутов сущности «Клиент» представлено в таблице 7.

Таблица 7 – Описание атрибутов сущности «Клиент»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_admin

int

PK

2

ID_ otdel

int

FK

3

Name

Varchar()

20

4

Tel

Varchar()

20

5

Adres

Varchar()

20

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

Таблица 8 – Описание атрибутов сущности «Отдел»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_otdel

int

PK

2

Name

Varchar()

20

Описание атрибутов сущности «Материал» представлено в таблице 9.

Таблица 9– Описание атрибутов сущности «Материал»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_mat

int

PK

2

Name

Varchar()

20

Описание атрибутов сущности «Шаги» представлено в таблице 10.

Таблица 10 – Описание атрибутов сущности «Шаги»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_tap

int

PK

2

ID_ zaavki

int

FK

3

Name

Varchar()

20

4

Data

Varchar()

20

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

Таблица 11 – Описание атрибутов сущности «Акт»

Номер

Поле

Тип поля

Размер поля

Ключевые

параметры

1

2

3

4

5

1

ID_akt

int

PK

2

ID_ zaavki

int

FK

3

Name

Varchar()

20

4

Data

Varchar()

20

5

Zena

Varchar()

20

Модель реальной базы данных на СУБД Microsoft SQL Server 2008 R2 представлена на рисунке 14.

Рисунок 14 - Модель БД проекта

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

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

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

Разработанная модель находится в третьей нормальной форме т.к.:

- атрибуты сущностей являются атомарными;

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

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

Созданная БД полностью замкнутая и обеспечивает полное функционирования данного приложения.

Данная БД является внешней по отношению к программной оболочке, к интерфейсу, разработанному на языке программирования С# и технологии Windows Forms.

3.3 Структурная схема пакета

В программном комплексе будут разработаны следующие модули, смотрите таблицу 12.

Таблица 12 - Программные модули системы

Наименование модуля

Функции модуля

1

Program.cs

Класс запуска

2

Model.cs

Класс моделей данных

3

BD.cs

Класс доступа к БД

4

Form_admin.cs

Класс для работы с данными об операторах

5

Form_klient.cs

Класс для работы с данными об клиентах

6

Form_otdel.cs

Класс для работы с данными об отделах

7

Form_zaavka.cs

Класс для работы с данными об заявках

8

Form_akt.cs

Класс для работы с данными об актах

9

Form_master.cs

Класс для работы с данными об мастерах

10

Form_mat.cs

Класс для работы с данными об материалах

11

Form_rachod.cs

Класс для работы с данными об расходах

12

Form_shag.cs

Класс для работы с данными об шагах

13

Form_sklad.cs

Класс для работы с данными об складе

14

Form1.cs

Класс стартового окна

15

Form_ot1.cs

Класс отчета по клиентам

16

Form_ot2.cs

Класс отчета по операторам

17

Form_ot3.cs

Класс отчета по отделам

18

Form_ot5.cs

Класс отчета по дате

3.4 Описание программных модулей

Общую структурную схему программного комплекса представим на рисунке 15 и 16.

Рисунок 15 - Структурная схема ПО(часть 1)

Рисунок 16 - Структурная схема ПО(часть 2)

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

  • Добавление, удаление и обновление клиентов;
  • Добавление, удаление и обновление отделов компании;
  • Добавление, удаление и обновление заявок;
  • Добавление, удаление и обновление операторов БД;
  • Добавление, удаление и обновление мастеров;
  • Добавление, удаление и обновление шагов ремонта;
  • Добавление, удаление и обновление параметров акта по ремонту;
  • Добавление, удаление и обновление материалов;
  • Добавление, удаление и обновление материалов на складе;
  • Добавление, удаление и обновление расходов материалов на складе;
  • Поиск клиентов;
  • Поиск материалов;
  • Поиск материалов на складе;
  • Поиск мастеров;
  • Поиск операторов БД;
  • Поиск заказов по клиенту;
  • Поиск заказов по мастеру;
  • Поиск заказов по оператору;
  • Формирование этапов ремонта заявки;
  • Формирование акта выполненных работ;
  • Отчеты заявки по клиентам;
  • Отчеты заявки по операторам;
  • Отчеты заявки по мастерам;
  • Отчеты заявки по датам;
  • Отчеты заявки по статусу;
  • Отчет остатки по складу
  • Авторизация;
  • Вывод отчета в Exсel документ.

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

Алгоритм обновления различных моделей рисунок 17.

Рисунок 17 - Алгоритм обновления

Алгоритм добавления модели рисунок 18.

Рисунок 18 - Алгоритм добавление модели

Удаление модели из БД рисунок 19.

Рисунок 19 - Алгоритм удаления модели данных

4. Контрольный пример реализации

4.1 Средства разработки

В качестве СУБД для реализации разрабатываемой системы был выбран Microsoft SQL Server. Причина выбора данной СУБД состоит в том, что она представляет собой компактную базу данных, развертывание которой возможно как на настольном компьютере, так и на смарт-устройстве или планшетном ПК, также неоспоримым преимуществом является то, что данная СУБД является бесплатной, что заметно уменьшает затраты на разработку и внедрение ИС. 

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

4.2 Описание программного обеспечения

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

Рисунок 20 - Стартовое окно программы

Далее можно пройти авторизацию если ты администратор или оператор БД, смотрите рисунок 21.

Рисунок 21 - Авторизация пользователя

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

Рисунок 22 - Учет отделов

Здесь пользователь может добавить, удалить, обновить и найти информацию об отделах.

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

Мы попадаем в окно для работы с сотрудниками организации, смотрите рисунок 23.

Рисунок 23 - Учет сотрудников

Здесь пользователь может добавить, удалить, обновить и найти информацию об сотрудниках.

Далее заявки. Мы попадаем в окно для работы с заявками данного сотрудника организации, смотрите рисунок 24.

Рисунок 24 - Учет заявок

Здесь пользователь может добавить, удалить, обновить и найти информацию о заявках.

Далее мастера. Мы попадаем в окно для работы с мастерами данной организации, смотрите рисунок 25.

Рисунок 25 - Учет мастеров

Здесь пользователь может добавить, удалить, обновить и найти информацию об мастерах.

Далее операторы БД. Мы попадаем в окно для работы с операторами данного отдела, смотрите рисунок 26.

Рисунок 26 - Учет операторов

Здесь пользователь может добавить, удалить, обновить и найти информацию об операторах.

Далее материалы. Мы попадаем в окно для работы с материалами данного отдела организации, смотрите рисунок 27.

Рисунок 27 - Учет материалов

Здесь пользователь может добавить, удалить, обновить и найти информацию об материалах.

Далее, с данного окна, можно попасть в окно склад. Мы попадаем в окно для работы со складом данного отдела, смотрите рисунок 28.

Рисунок 28 - Учет материалов на складе

Здесь пользователь может добавить, удалить, обновить и найти информацию об материалах на складе.

Далее этапы выполнения заявки. Мы попадаем в окно для работы с тапами выполнения заявок, смотрите рисунок 29.

Рисунок 29 - Учет этапов выполнения заявок

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

Далее акты. Мы попадаем в окно для работы по формированию актов по выполненным работам, смотрите рисунок 30.

Рисунок 30 - Учет актов

Здесь пользователь может добавить, удалить, обновить и найти информацию об актах.

Далее расход материалов. Мы попадаем в окно для работы с расходом материалов при ремонте конкретной заявки, смотрите рисунок 31.

Рисунок 31 - Учет материалов

Здесь пользователь может добавить, удалить, обновить и найти информацию о расходе материалов при ремонте конкретной заявки.

4.3 Отчеты по отделу

В результате своей деятельности программный комплекс формирует много отчетов. Все они выводятся в EXCELдокумент для дальнейшего использования.

А именно:

  • Сохранить как резервную версию;
  • Перевести в WORD документ;
  • Распечатать для руководителя;
  • Распечатать для бумажной БД.

4.4 Тестирование

На этом этапе представим доказательства того, что спроектированное ПС работает в соответствии с требованиями.

Тест кейсы представим в таблице 12.

Таблица 12 - Таблица тестов программы

Суть

Шаги

Ожидаемый результат

Да/Нет

1

Проверка запуска программы

1.Запуск программы

2. Открытия главного окна

Наблюдения стартового окна

Да

2

Проверка добавления отдела

1.Запуск программы

2. Авторизация

3. Отделы Добавить

4. Заполнить корректно поля

5. Кликнуть кнопку "Добавить"

Наличие новой

информации

в БД

Да

3

Проверка ввода данных при добавления данных

1.Запуск программы

2. Авторизация

3. Отделы. Добавить

4. Заполнить не корректно поля

5. Кликнуть кнопку "Добавить"

Наличие сообщения об ошибке ввода данных

Да

4

Проверка наличия всех отделов

для выбора

1.Запуск программы

2. Ввод логина и пароля

3. Авторизация

4. Отделы. Добавить

5. Таблица по центру

Наличие списка отделов

Да

5

Проверка возможности

просмотра информации

об клиентах

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отдела. Клиенты

Получение информации об

клиентах

Да

6

Проверка возможности

просмотра информации заявках

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки

Получение информации об заявках

Да

7

Проверка возможности

просмотра информации об операторах БД

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Операторы БД.

Получение информации об операторах БД

Да

8

Проверка возможности

просмотра информации мастерах

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Мастера.

Получение информации об мастерах

Да

Продолжение таблицы 12

Суть

Шаги

Ожидаемый результат

Да/Нет

9

Проверка возможности

просмотра информации об материалах

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Материалы.

Получение информации об материалы

Да

10

Проверка возможности

просмотра информации об расходах

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Расходы.

Получение информации об расходах

да

11

Проверка возможности

просмотра информации об актах

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Акты.

Получение информации об актах

Да

12

Проверка возможности

просмотра информации шагах заявки

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Шаги.

Получение информации об шагах

Да

13

Проверка возможности

удаления информации об складе

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Материалы. Склад

Получение информации об складе

Да

14

Проверка возможности

Обновления

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

1.Запуск программы

2. Авторизация

3. Отделы

4.Выбор отдела и изменения данных.

5. Обновить

Обновление необходимой информации

Да

15

Возможность

просмотра информации

о заявках по оператору

1.Запуск программы

2. Открытия главного окна

3. Отделы. Отчеты

4. Далее "По оператору"

5. Выбор списка

6. Старт

Наличие необходимого отчета.

Да

16

Возможность

просмотра информации

о заявках по мастеру

1.Запуск программы

2. Открытия главного окна

3. Отделы. Отчеты

4. Далее "По мастеру"

5. Выбор списка

6. Старт

Наличие необходимого отчета.

Да

17

Возможность

просмотра информации

о заявках по отделу

1.Запуск программы

2. Открытия главного окна

3. Отделы. Отчеты

4. Далее "По отделам"

5. Выбор списка

6. Старт

Наличие необходимого отчета.

Да

Продолжение таблицы 12

Суть

Шаги

Ожидаемый результат

Да/Нет

18

Возможность

просмотра информации

о остатках по складу

1.Запуск программы

2. Открытия главного окна

3. Отделы. Отчеты

4. Далее "Остатки"

Наличие необходимого отчета.

Да

19

Проверка авторизации

1.Запуск программы

2. Открытия главного окна

3. Ввод неверного логина и пароля. Ввод

Сообщение об ошибке

20

Возможность

просмотра информации

о шагах по заявке

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Шаги.

Наличие необходимой информации.

Да

21

Возможность

просмотра информации

об актах по заявке

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Акты.

Наличие необходимой информации.

Да

22

Формирование отчета в EXCEL документе об актах

1.Запуск программы

2. Открытия главного окна

3. Авторизация

4. Отделы. Клиенты. Заявки.

Акты.

5. Печатать. EXCEL

EXCEL документ о выполненных работах

Да

Заключение

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

Система реализована средствами C#. В качестве хранения данных использовался сервер Microsoft SQL SERVER.

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

Список литературы

1. Агуров П.А. С#. Разработка компонентов в MS Visual Studio 2008/2010.СПб.: БХВ –Петербург, 2018. 480с.

2. Марченко А.Л. C#. Введение в программирование. Учебное пособие. М.: МГУ им. М.В. Ломоносова ,2016. 317с.  

3. Биллиг В.А. Основы программирования на C#//Учебное пособие. 2017. URL:http://www.intuit.ru/department/pl/csharp

4. Чен П.П. Модель “сущность-связь” – шаг к единому представлению данных. СУБД, N3, 2015 г.

5. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М., Финансы и статистика, 2016.

6. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., Финансы и статистика, 2015.

7. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. М., Мир, 2015.