Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Министерство образования Республики Беларусь
Министерство образования и науки Российской Федерации
Государственное учреждение высшего
профессионального образования
"БЕЛОРУССКО-РОССИЙСКИЙ УНИВЕРСИТЕТ"
Кафедра " Автоматизированные системы управления "
Курсовой проект
по дисциплине "Базы и банки данных"
Разработка многопользовательской информационной системы
"Service Desk"
|
Допущен: «_»__2012_г _____ Защитил: «_»__2012_г _____ Оценка__________ Комиссия: _________ |
Выполнил студент гр. АСОИЗ-081 _______ Д.С. Базылев Шифр 081645 Руководитель:____ Захарченков К.В. |
Могилёв, 2012
Содержание
|
[1] Введение [2] 1. Техническое задание [3] 1.1. Анализ предметной области [4] 1.2 Постановка задачи
[5] [6] 2.1. Функциональная модель [7] 2.1.1. Контекстная диаграмма и диаграммы детализации процессов [8] 2.1.2. Диаграмма дерева узлов
[9] [10] 2.2.1. Идентификация сущностей и связей. ER-диаграмма логического уровня. [11] 2.2.2. ER-диаграмма физического уровня. Ограничения ссылочной целостности [12] 2.3 Верификация спроектированной логической модели.
[13] [14] 4. Результаты тестирования информационной системы
[15] |
В современном мире персональные компьютеры стали неотъемлемым атрибутом человеческой жизни. Сейчас человеку в его повседневной деятельности все чаще необходимо искать информацию в разных источниках, хранить и обрабатывать огромные массивы информации. С появлением компьютеров часть этих операций было передано машине.
Для успешной реализации проекта информационной системы объект проектирования должен быть адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели системы.
До недавнего времени проектирование информационных систем выполнялось на интуитивном уровне, с использованием неформализованных методов – методов, основанных на практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества информационной системы.
В процессе создания информационной системы потребности пользователей могут изменяться и уточняться, что ещё более усложняет разработку.
В 70-80-х годах при разработке информационных систем применялась структурная методология. Она основана на наглядной графической технике. Однако ручная разработка приводила к следующим проблемам:
1.Сложно обнаруживать ошибки в проектных решениях;
2.Документация имеет низкое качество;
3.Тестирование требует длительного времени и часто даёт неудовлетворительные результаты.
Эти проблемы способствовали появлению прграммно-технологических средств специального класса CASE.
Сейчас для хранения и обработки информации широко используются СУБД различных типов (Clipper, Paradox, FoxPro), наибольшее распространение получили реляционные СУБД (ACCESS). Они имеют наиболее понятный и наглядный интерфейс, вся информация хранится в виде отдельных таблиц, с которыми практически все встречались в повседневной деятельности. В настоящее время практически на любом компьютере установлен пакет Microsoft Office, компонентом которого является СУБД – ACCESS.
Целью данного курсового проекта является проектирование и реализация базы данных для предметной области «Service Desk», а также реализация всех необходимых для данной предметной области запросов.
Service Desk - это - некоторая диспетчерская служба, которая в полной мере ответственна перед клиентом или пользователем за предоставление согласованных с ним сервисов, является центром приема всех жалоб и предложений, осуществляет контроль текущего состояния сервисов и имеет полномочия по выдаче нарядов на устранение возможных сбоев, а также на контроль процесса устранения неисправностей. В самом общем виде данная служба может осуществлять перечисленные функции в отношении всех сервисов (а не только информационно-технологических), предоставляемых организацией и ее отдельными подразделениями.
В самом общем виде Service Desk обеспечивает единую точку контакта для пользователей организации. Service Desk отстаивает интересы клиента перед остальным персоналом. Service Desk несет ответственность за устранение возникшего инцидента. Даже если реально работы выполняются специалистами других подразделений, полный учет времени устранения инцидента, контроль за процессом устранения, информирование пользователя о состоянии проблемы, информирование руководства о задержках в устранении их причинах, все это -обязанности службы Service Desk.
Служба технической поддержки часто организована по следующему многоуровневому принципу:
Пользователь – обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки;
Оператор – регистрирует обращение, при возможности помогает пользователю самостоятельно, либо передаёт и контролирует выполнение;
Вторая линия поддержки – получает заявки от первой линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из смежных отделов (системные администраторы, иненера-системотехники, поддержка специального ПО, поддержка специального оборудования и т. д.).
При отсутствии автоматизации планирование устранения возникающих инцидентов происходило вручную:
Контекстная IDEF0-диаграмма представлена на рисунке 1. Диаграммы детализации процессов представлены на рисунках 2-4.
Рисунок 1 – Контекстная IDEF0-диаграмма
Рисунок 2 – IDEF0-диаграмма детализации процесса «Организовать работу службы Service Desk»
Рисунок 3 – DFD-диаграмма детализации процесса «Организовать назначение заявки специалисту»
Рисунок 4 - DFD-диаграмма детализации процесса «Организовать регистрацию заявки»
Диаграмма дерева узлов представлена на рисунке 5.
Рисунок 5 – Диаграмма дерева узлов
Для информационной системы “Service Desk” созданы следующие сущности:
1.Сущность «Заявки» вводится для хранения информации о инцидентах, зарегистрированных диспетчером.
2.Сущность «Инициатор» хранит информацию о пользователях, сообщивших о инциденте.
3.Сущность «Исполнитель» вводится для хранения информации о сотрудниках отдела, решающих проблемы инициатора.
4.Сущность «Тип заявки» вводится для хранения информации о всех заявках и их статусах.
5. Сущность «Структурное подразделение» вводится для хранения информации о всех структурных подразделениях, существующих на предприятии.
Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями. В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При это в месте "стыковки" связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности.
ER-диаграмма логического уровня представлена на рисунке 6.
Рисунок 6 - ER-диаграмма логического уровня
На логическом уровне проектирования в данной базе данных присутствуют четыре определенных связи:
1.связь между сущностями «Заявки» и «Тип заявки» типа один к одному означает, что у каждой заявки свой единственный статус и расширенная информация. Связь является неидентифицирующей, поскольку для идентификации заявки нет необходимости знать номер заявки;
2. связь между сущностями «Заявки» и «Исполнитель» типа один ко многим означает, что у каждого исполнителя может быть множество заявок. Связь является неидентифицирующей, поскольку для идентификации заявки нет необходимости знать табельный номер исполнителя;
3. связь между сущностями «Заявки» и «Инициатор заявки» типа один ко многим означает, что один клиент может сделать несколько множество звонков и зарегистрировать множество совершенно разных заявок. Связь является неидентифицирующей, поскольку для идентификации заявки нет необходимости знать табельный номер инициатора;
4. связь между сущностями «Инициатор» и «Структурное подразделение» типа один ко многим означает, что в каждом структурном подразделении может быть множество сотрудников, каждый из которых может в любое время стать инициатором заявки. Связь является неидентифицирующей, поскольку для идентификации заявки нет необходимости знать номер структурного подразделения;
ER-диаграмма физического уровня представлена на рисунке 7.
Рисунок 7 - ER-диаграмма физического уровня
Ссылочная целостность реализована в базе данных следующим образом:
Таблица 1 - Отчет о верификации модели
|
Arrow Name |
Entity Name |
Attribute Name |
|
Заявки о тпользователей |
Заявки |
Таб_номер_инициатора |
|
Местоположение |
||
|
Тема |
||
|
Описание |
||
|
Таб_номер_исполнителя |
||
|
Номер_заявки |
||
|
Запчасть |
||
|
Инициаторы |
Инициатор |
Таб_номер_инициатора |
|
Фамилия |
||
|
Имя |
||
|
Отчество |
||
|
Должность |
||
|
Контактный_телефон |
||
|
Номер_структурного_подразделения |
||
|
Исполнители |
Исполнитель |
Таб_номер_исполнителя |
|
Фамилия |
||
|
Имя |
||
|
Отчество |
||
|
Контактный_ном_телефона |
||
|
Должность |
||
|
Типы заявок |
Тип заявки |
Адрес_организации |
|
Наименование_заказчика |
||
|
Номер_заказчика |
||
|
Телефон_организации |
||
|
Структурные подразделения |
Структурное подразделение |
Номер_заявки |
|
Статус |
||
|
Примечание |
При запуске приложения на экране появляется главная форма (рисунок 8).
Рисунок 8 – Главная форма клиентского приложения
При щелчке по кнопке «Таблицы» осуществляется переход к форме «Таблицы» (рисунок 9)
Рисунок 9 – Форма «Таблицы»
При щелчке по кнопке «Инициатор» на форме «Таблицы» выводится форма «Инициатор» (рисунок 10), на которой содержится информация о сотрудниках предприятия.
Рисунок 10 – Форма «Клиенты»
Аналогичным образом с формы «Таблицы» открываются формы для других таблиц.
При щелчке по кнопке «Запросы» на главной форме осуществляется переход к форме «Запросы» (рисунок 11), каждая из кнопок которой выполняет соответствующий запрос.
Рисунок 11 – Форма «Запросы»
В разработанной информационной системе реализованы следующие запросы:
1) Перечень заявок, зафиксированных по указанному местоположению
SELECT Заявки.Таб_номер_инициатора, Заявки.Тема, Заявки.Описание, Заявки.Запчасть, Заявки.Местоположение
FROM Заявки
WHERE (((Заявки.Местоположение)=[Введите местоположение]));
2) Перечень заявок, зафиксированных инициатором с указанной фамилией
SELECT Инициатор.Фамилия, Инициатор.Должность, Инициатор.Контактный_телефон, Заявки.Местоположение, Заявки.Тема, Заявки.Описание
FROM Инициатор INNER JOIN Заявки ON Инициатор.Таб_номер_инициатора = Заявки.Таб_номер_инициатора
WHERE (((Инициатор.Фамилия)=[Введите фамилию инициатора]));
3) Перечень заявок, зафиксированных в заданном структурном подразделении
SELECT [Структурное подразделение].Название_подразделения, Инициатор.Фамилия, Инициатор.Должность, Заявки.Тема, Заявки.Описание
FROM [Структурное подразделение] INNER JOIN (Инициатор INNER JOIN Заявки ON Инициатор.Таб_номер_инициатора = Заявки.Таб_номер_инициатора) ON [Структурное подразделение].Номер_структурного_подразделения = Инициатор.Номер_структурного_подразделения
WHERE ((([Структурное подразделение].Название_подразделения)=[Введите название структурного подразделения]));
4) Перечень заявок, имеющих статус «Открыто»
SELECT Заявки.Тема, Заявки.Местоположение, [Тип заявки].Статус
FROM Заявки INNER JOIN [Тип заявки] ON Заявки.Номер_заявки = [Тип заявки].Номер_заявки
WHERE ((([Тип заявки].Статус)="Открыто"));
5) Список заявок, назначенных исполнителю, указанному пользователем
SELECT Исполнитель.Фамилия, Заявки.Тема, Заявки.Описание
FROM Исполнитель INNER JOIN Заявки ON Исполнитель.Таб_номер_исполнителя = Заявки.Таб_номер_исполнителя
GROUP BY Исполнитель.Фамилия, Заявки.Тема, Заявки.Описание
HAVING (((Исполнитель.Фамилия)=[Введите фамилию исполнителя]));
6) Список работников организации, которые могут выступать в роли инициатора заявки
SELECT Инициатор.Фамилия, Инициатор.Имя, Инициатор.Отчество, Инициатор.Должность
FROM Инициатор;
7) Поиск исполнителя по его должности
SELECT Исполнитель.Фамилия, Исполнитель.Имя, Исполнитель.Отчество, Исполнитель.Должность
FROM Исполнитель
WHERE (((Исполнитель.Должность)=[Введите должность исполнителя]));
8) Список сотрудников, работающих в структурном подразделении, указанном пользователем
SELECT Инициатор.Фамилия, Инициатор.Имя, Инициатор.Отчество, [Структурное подразделение].Название_подразделения
FROM [Структурное подразделение] INNER JOIN Инициатор ON [Структурное подразделение].Номер_структурного_подразделения = Инициатор.Номер_структурного_подразделения
WHERE ((([Структурное подразделение].Название_подразделения)=[Введите название структурного подразделения]));
Программный продукт был протестирован, в качестве тестовых в базу данных было введено количество записей, достаточное для проверки всех функций системы (вывода результатов выполнения запросов и формирования отчетов).
Результат тестирования показал совпадение итоговых значений с расчетными данными. Из этого можно сделать вывод, что созданное программное обеспечение работает правильно и готово к эксплуатации.
Программный продукт переносится на гибких дисках и может быть установлен на любом компьютере, где установлена СУБД Access 2000, а также более поздние версии.
Заключение
В ходе выполнения технического задания спроектирована многопользовательская информационная система, произведена автоматизация учета вызовов отдела АиОС. Созданная система позволяет посредством удобного интерфейса получать быстрый доступ к данным.
При создании информационной системы использовались СУБД Microsoft ACCESS 2000, средство моделирования баз данных All Fusion Data Modeler 4.1, средство моделирования бизнес-процессов All Fusion Process Modeler 4.1.
Проведенное тестирование разработанной информационной системы показало, что она работает корректно и готова к использованию.